Changelog

Consumer-facing changes, newest first.

Consumer-facing changes to the Bridge API, newest first. Internal refactors don't appear here; anything wire-visible must. Deprecations follow the deprecation policy.

Unreleased

• Imports now complete the way a worker fetch does. After a general-ledger or opening-balance import finishes, the import engine records the fetch completion, so the ledger's "last updated" timestamp moves, the fetch appears in the fetch-runs view, and auto-reconciliation and the other post-fetch engines run for API-managed companies exactly as for ERP-connected ones. The import result gains an additive fetchCompletion object (status: completed, failed with a failureType, ignored, error, or unreported); the import itself never fails because of it.

• Developer portal: agent skill. The overview page has an Add the API skill button. It installs accountflow-api, a skill for AI coding agents that carries the API's rules (auth, idempotency, retries, pagination, import order, refused deletions) with the OpenAPI spec and the guides bundled as references, generated per environment at /skills/accountflow-api.zip. The Imports section now shows in the navigation of every portal page; it was missing on the API reference.

• Imports. Companies bound to the Api accounting system can now receive their books through the API (scope imports:write, docs/adr/0031). Six kinds, each POST /v1/companies/{companyId}/imports/<kind> with up to 10 000 lines, answering 202 with an import to poll at GET /v1/companies/{companyId}/imports/{importId} (GET /v1/companies/{companyId}/imports lists them): accounts, dimensions, sub-ledgers, opening-balances, general-ledger-lines (merge by id; replace is not available yet) and open-items (the import contract's shape, with sourceDeleted and snapshot modes as the way to retire items). Lines carry your own id; general-ledger reads now show it as sourceLineId. Opening balances and general-ledger lines refuse account codes missing from the year's chart (422, reason: unknown_account_codes), periods are 1–12, one import per kind and company runs at a time (409, reason: job_in_flight), a company not bound to the Api system answers 409, reason: company_not_api_managed, and more than 10 000 lines is 413 payload_too_large. New event import.requested.

• Corrections. What was pushed wrongly can be removed with the same scope and the same 202-and-poll model: POST …/imports/general-ledger-lines/deletions and POST …/imports/opening-balances/deletions ({year, ids}), and DELETE /v1/companies/{companyId}/accounts/{accountNumber}, …/dimensions/{key}, …/sub-ledgers/{key}. Nothing that work in the application depends on is ever deleted, and nothing cascades: such a request answers 409 with reason (lines_in_use, opening_balances_in_use, account_in_use, dimension_in_use, sub_ledger_in_use) and an inUse list of your ids with what depends on each, and deletes nothing. Deleted lines keep their full history. To change a line's values, re-send it with the same id; to retire an account that has history, import it with hidden: true. New event correction.requested.

• Import readiness. GET /v1/companies/{companyId}/imports/readiness is the preflight: whether the company is bound to the Api accounting system, what each API-managed year already holds (accounts, mapped accounts, opening balances, general-ledger lines), blockers, warnings and the nextStep. New guides: Importing data and Correcting data.

• Dimension and sub-ledger reads. GET /v1/companies/{companyId}/dimensions and …/sub-ledgers (scope ledger:read, also MCP tools list_dimensions and list_sub_ledgers) list the keys general-ledger lines and open items refer to.

• Context bundles (MCP only). Two new tools, get_company_context and get_account_context, return what a company or a ledger account means: identity, standard-chart mapping, and the routine/instructions the accountant registered, as compact Markdown with asOf, sources and suggestedOperations. They exist on the MCP surface only (19 tools now), behind the new scope context:read, which only an interactive session can hold: there is no REST endpoint and machine clients cannot be granted the scope. Existing connectors must re-consent to pick the scope up. A bundle for an account you can read but the ontology has not caught up with yet is a service_unavailable tool error asking you to retry, never a not-found.

• get_caller_identity now answers the question for humans too. New additive fields: userId — the person every authorization check runs as (USER and INTERACTIVE modes; null for SYSTEM) — and, for interactive sessions, organizationIds, the organizations the person belongs to. Previously an interactive caller got only the shared client id and a null organization, which identified nobody.

• MCP endpoint (beta). POST /mcp speaks the Model Context Protocol over stateless streamable HTTP. Sign in as yourself (OAuth 2.1 authorization-code + PKCE via the Accountflow login, consenting to exactly the scopes the client requests) and every read operation you could call over REST is available as a tool — 19 today, scoped to your own access. The organization directory and access administration stay off the MCP surface entirely (users:read, access:manage, webhooks:manage are not available to interactive sessions, regardless of consent). Discovery follows RFC 9728: an unauthenticated call returns a WWW-Authenticate challenge pointing at /.well-known/oauth-protected-resource/mcp. Mutations are not yet available over MCP; they arrive in a later phase.

Documentation and specification quality; no behavioural change to any endpoint.

• The published spec is now OpenAPI 3.0.3. 3.1 expresses "may be null" as a type union, which reference renderers show as null — hiding what the field actually holds — and which most client generators handle poorly. Nullable fields now read as their declared type plus nullable: true. A few nullable nested objects were previously typed null outright; they now carry their real type.
• The reference now documents how to get a token. The client-credentials token endpoint is published as the reference's first section, with its request form, token response, and the OAuth 2.0 error shape the authorization server returns (which is not this API's problem-document shape). Its URL follows the environment you are reading about.
• Client credentials is the only documented flow. The authorization-code (PKCE) flow was listed but cannot be completed today — the interactive client it needs does not exist yet. It returns with the MCP integration.
• Every response documents its schema. Success responses previously had no declared body type; each endpoint now publishes its full response structure, nested objects and arrays included.
• Every operation documents its failure shape: 400 and 500 entries with the shared problem-document schema.
• Free-form JSON fields (job parameters and results, webhook delivery payloads) are published as free-form objects instead of the serializer's internals.

1.0.0-rc1 — 2026-08-20 (testing phase)

The complete /v1 surface, in pre-GA testing. The additive-only freeze (deprecation policy) takes effect at GA; until then breaking changes remain possible with ordinary review.

Surfaces

• Companies — read (disabled visible with status, deleted 404), create, update, and the full lifecycle (disable / enable / delete / restore).
• General ledger — chart of accounts, cursor-paginated GL lines with stable line ids, trial balance (opening, monthly movements, closing).
• VAT — filing terms with reconciliation status and decimal NOK totals.
• Users — org membership reads and per-user effective access.
• Access management (system clients only) — policy documents with rules, assignment and revocation, converging automatically to the authorization layer.
• Documents — two-step signed-URL uploads, signed downloads, metadata, lifecycle; binaries never pass through the API.
• Bank & reconciliation — accounts, transaction feed with computed reconciliation status, reconciliation groups, per-period summary, and the two mutations: reconcile and unmatch.
• Jobs — 202-and-poll for heavy operations, one in-flight per scope.
• Webhooks — signed thin events mirroring the audit catalog, verification handshake, retries with dead-lettering and auto-disable, delivery log.

Platform guarantees

• OAuth 2.0 (client credentials; authorization code + PKCE for interactive, read-only for now), resource:action scopes.
• Idempotency-Key on every mutation with byte-identical replays.
• Opaque signed cursors; keyset pagination everywhere.
• RFC 9457 errors with a documented catalog.
• Rate plans: standard 300 req/min (burst 60), premium 1200 req/min (burst 240).