Every operation in the Ledger Layer engine is REST-accessible: lease and revenue ingest, engine runs (initial, modification, remeasurement, termination, catch-up), batch monthly close, full journal lifecycle (approve / batch-approve / reverse / void / posting-reference), period locks, SSP matrix management, policy snapshots, unified disclosure packs (single-standard or COMBINED IFRS 15 + ASC 606), and auditor narrative overrides. Bearer-token auth, role-gated, idempotent POST, HMAC-signed webhooks. Same engine, same audit trail, same approval gates as the UI.
Quick start: Sign up, generate an API token in the dashboard, and make your first request. The sandbox environment mirrors production — test with real lease data in a safe, isolated tenant. API keys, the full OpenAPI 3.1 schema, and Postman collections are available immediately after signup.
POST /revenue/contracts/confirmauto-runs INITIAL_RECOGNITION per standard, with retry capture on failurePOST /revenue/contracts/:id/recalculateopt-in re-run after policy or input changesPOST /revenue/engine/monthly-closebatch revenue close per entity × standard, idempotentGET /revenue/disclosures?format=packunified pack; scope=COMBINED merges IFRS 15 + ASC 606GET + PUT /revenue/disclosures/narrative-overrideauditor narrative override on revenue packs (APPROVER+)GET /revenue/journals/summary · /exportrollup + XLSX/CSV/JSON export to feed any ERPGET + PUT /lease/period-locksfirst-class lease period locks; engine enforces at entryGET + PUT /lease/disclosures/narrative-overrideauditor narrative override on lease packsPUT /revenue/ssp-matrix · /period-lockSSP matrix + period-lock controls for IFRS 15 closePOST + GET /revenue/policy-snapshotsbind revenue policy elections to an entityAll API requests require a Bearer token in the Authorization header. Tokens are scoped to a tenant and carry the role of the authenticating user (OWNER, ADMIN, APPROVER, PREPARER, REVIEWER). AI agents authenticate with the same token format — role-gated access applies equally to humans and agents. Token generation and revocation are managed in the dashboard.
Tokens are long-lived but revocable. Each token is tied to a specific user and tenant. When an API request is made, the token is validated, the role is checked against the endpoint's permission requirements, and the request is logged in the audit trail with the actor identity, timestamp, and request ID. Failed authorisation attempts are logged but not retried.
All list endpoints return cursor-based pagination. Pass cursor=<value> from the previous response to fetch the next page. Default page size is 50; max is 200. Most list endpoints support filtering by entity, period, standard, status, and date range.
Cursor-based pagination is stable — new records added during pagination do not cause duplicates or missed records. Filters are applied server-side before pagination. Sort order is configurable on most endpoints (e.g., sort=created_at:desc). The response includes total_count, has_more, and next_cursor fields.
Subscribe to engine events via webhooks: lease.confirmed, lease.modified, journal.created, journal.approved, journal.reversed, close.completed, disclosure.generated, and more. Each webhook payload is signed with HMAC-SHA256 using your webhook secret — verify the signature before processing.
Webhooks are configured in the dashboard per tenant. Each event type can be routed to a different URL. Failed deliveries are retried with exponential backoff (up to 5 attempts over 24 hours). Event payloads include the full resource representation at the time of the event, plus metadata (event_id, event_type, timestamp, actor, request_id).
All errors return a structured JSON body with code (machine-readable), message (human-readable), request_id (for audit trail correlation), and optional details (field-level validation errors). Standard HTTP status codes: 400 validation, 401 authentication, 403 authorisation, 404 not found, 409 conflict, 422 engine rejection, 429 rate limit.
The request_id appears in the audit trail and in webhook payloads — use it for end-to-end tracing and support tickets. Engine rejection errors (422) include the specific engine rule that was violated, making it possible to diagnose and fix the input without contacting support. Validation errors (400) include per-field error details.
Starter: 100 req/min. Professional: 500 req/min. Enterprise: custom. Rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) are included on every response. Engine run endpoints are asynchronous — POST /engine/run returns a job ID; poll GET /engine/jobs/:id for status or subscribe to the engine.completed webhook.
Rate limits are applied per token, not per IP. Burst allowance is 2x the per-minute limit for short spikes. When the limit is exceeded, the API returns 429 with a Retry-After header. Asynchronous engine runs do not count against the request rate limit after the initial POST.
All POST endpoints support idempotency keys via the Idempotency-Key header. Sending the same key within 24 hours returns the original response without re-executing the operation. This is critical for engine runs and journal approvals — retrying a failed network request will not create duplicate entries.
Idempotency keys are scoped to the tenant and endpoint. The stored response is returned with a 200 status and an X-Idempotent-Replayed: true header. Keys expire after 24 hours. GET requests are naturally idempotent and do not require the header.
The journal export endpoint emits approved journal entries in structured CSV, XLSX, and JSON formats — ready to feed into any ERP, iPaaS, or middleware (Alteryx, Anaplan, n8n, Workato, Zapier, Airflow, Dagster, or your own). Combined with the MCP tool surface and outbound webhooks, Ledger Layer plugs into SAP, Oracle, NetSuite, or any downstream system via the tool of your choice.
Export format is specified via the format query parameter (csv, xlsx, json). Account mapping is configured per entity in the dashboard — map Ledger Layer account codes to your chart of accounts once, and every export uses the mapping automatically. Exports are generated from immutable, approved journal entries only. For event-driven flows, subscribe to journal.approved and close.completed webhooks and drive downstream posting from any middleware that can receive an HTTP callback.
Every Ledger Layer account includes a sandbox tenant that mirrors the production API. Test with real lease data, run the engine, generate disclosures — all without affecting your production data. The sandbox uses the same endpoints, authentication, and rate limits as production.
Sandbox data is isolated from production. You can reset the sandbox at any time from the dashboard. The sandbox is ideal for integration testing, CI/CD pipelines, and onboarding new team members. API tokens are scoped to either sandbox or production — they cannot cross tenants.
POST /leases/extract-file with the workbook → review extracted terms → POST /leases/confirm → engine runs automatically → GET /journal-entries/export for the output. The entire flow is API-driven.
POST /revenue/contracts/extract/file → PATCH /revenue/contracts/:id to correct any fields → POST /revenue/contracts/confirm → INITIAL_RECOGNITION auto-chains per configured standard. Failed runs land in the DLQ; retry with POST /revenue/contracts/:id/recalculate.
PUT /lease/period-locks to unlock the period → POST /engine/monthly-close → subscribe to close.completed webhook → PUT /lease/period-locks to re-lock → GET /journal-entries/export in your ERP format.
POST /revenue/engine/monthly-close per entity × standard (idempotent) → GET /revenue/journals/summary for rollup → GET /revenue/journals/export to push to the ERP → PUT /revenue/period-lock to freeze the period.
GET /revenue/disclosures?format=pack&scope=COMBINED returns IFRS 15 + ASC 606 side-by-side. PUT /revenue/disclosures/narrative-override (per standard) lets auditors inject final narrative without re-running the engine.
Connect your AI agent (Claude, GPT, n8n) via MCP or REST API. The agent queries the portfolio, surfaces leases / contracts needing attention, and drafts summaries — but cannot approve without human sign-off. All approval gates apply equally to agents and humans.
Every API response includes request_id. Every journal entry includes actor, timestamp, and source operation. Engine-run lineage (reversal_of_run_id, supersedes_run_id, base_run_id) ties modifications back to the original recognition. Feed these into your GRC platform for continuous audit monitoring.
Before lease_confirm, call lease.validate_enhanced via MCP to surface business-rule issues (missing payment streams, IBR/FX gaps, short-term exemption hints). Block confirmation on errors; show warnings to the reviewer. Keeps bad data out of the engine.
API keys, sandbox environment, full OpenAPI 3.1 schema, and Postman collections — all available in the dashboard after signup.