Changelog

Consumer-facing changes, newest first.

Changes to the Accountflow API, newest first. Anything visible on the wire is listed here; deprecations follow the deprecation policy.

Unreleased

The API is in its pre-GA testing phase (1.0.0-rc), so this release still contains breaking changes. Each one is listed first, with what to change on your side.

Breaking

• One naming rule. JSON fields, query parameters and path parameters are camelCase. Renamed: pagination.nextCursor and pagination.hasMore (were next_cursor, has_more); query parameters pageSize and reconciliationStatus (were page_size, reconciliation_status); webhook payload keys occurredAt and data.resourceType, data.resourceId, data.organizationId. Error codes and reason values stay snake_case. Webhook signatures are unchanged.
• pageSize outside 1–200 is refused with 400 validation_failed instead of being silently clamped.
• Actions are POST …/actions/<verb>: /v1/companies/{companyId}/actions/restore, /v1/documents/{documentId}/actions/complete and /v1/documents/{documentId}/actions/restore (previously without actions/).
• DELETE /v1/companies/{companyId} takes no body. The optional audit note is the query parameter ?reason= (up to 200 characters).
• Access-policy rules carry scopeType (COMPANY, ORGANIZATION, PORTFOLIO) and, for portfolio rules, portfolioId. Portfolio rules created in the application now grant exactly the portfolio's companies.
• Reconciliation summary approvalStatus is APPROVED, REVOKED or null; the value STALE no longer exists.
• MCP sign-ins are for MCP. A token issued to an MCP client (sign-in through Accountflow's login page) is accepted on /mcp only; on /v1 it is refused with 403 capability_denied. Integrations use client credentials, as before. The scopes an MCP client may request are now the read scopes plus context:read (/.well-known/oauth-protected-resource/mcp); MCP sessions were already read-only.
• API clients created in the application are bound to their service account. A token must carry the service account's sub recorded when the client was created; anything else is refused like an unknown client (401).
• Webhook verification needs an HMAC answer. A new or re-pointed endpoint must answer the webhook.verification request with a 2xx whose body contains the lowercase hex HMAC-SHA256(key = the endpoint's signing secret, message = challenge), for example {"challengeResponse": "<hex>"}. Echoing the challenge no longer verifies an endpoint. The webhooks guide has a test vector.
• Document uploads must send the signed headers. The PUT to the signed upload URL must carry every header in the new upload.headers (Content-Type, x-goog-content-length-range and x-goog-if-generation-match: 0). Storage refuses a body larger than the declared sizeBytes, and the URL can create the file once but never replace it.
• Write bodies refuse unknown fields. Company, access-policy, document, webhook-endpoint and bank-reconciliation write bodies answer 400 validation_failed for a property they do not define, instead of ignoring it.
• New input limits on writes (400 validation_failed, the limits are in the reference): company name ≤ 255, companyNumber and companyType ≤ 32, countryCode two letters, obMonth 1–12; access policies at most 500 rules, 1000 accountIds per rule, description ≤ 2000; document displayName and mimeType ≤ 255; webhook url ≤ 2048, description ≤ 500, at most 100 eventTypes; bank reconciliations at most 500 transactionIds and 500 lineIds, note ≤ 2000, period 1–12.
• vatEnabled defaults to false when omitted on company create, as in the application (it defaulted to true).
• list_account_status cursors minted before this release answer 400 invalid_cursor; start again from the first page.
• Company automation follows the application's rules. autoApprove can only be on while automatic reconciliation is on — for the company (autoReconcile) and for each module on its own enabled; a change that would leave it on beside switched-off automation answers 400 validation_failed with reason: auto_approve_requires_automation (turn both off in one change). SIMPLE_BANK and BALANCE match no lines and refuse a matchWindowDays or secondPassEnabled other than the one the settings already show (sending back the value you read changes nothing and is accepted). Either refusal's parameter names the field as your request has it: autoApprove on PATCH …/settings/automation/modules/{module}, automation.modules.<MODULE>.autoApprove in the combined settings change. Balance-template accounts are now their own module, BALANCE, in the settings response and on PATCH …/settings/automation/modules/BALANCE; GENERAL_LEDGER no longer stands for them. An unset secondPassMaxOpenLines reads as 100, the value reconciliation uses (it read 70).

Added

• analyze on uploads. POST /v1/companies/{companyId}/documents takes an optional analyze (default true). Where the company has document analysis switched on, a completed upload is read for its type and details; analyze: false keeps that file out. It cannot switch analysis on for a company that has it off.

• Uploads are scanned. POST /v1/documents/{documentId}/actions/complete now checks the uploaded file against its declared type and scans it for malware before the document exists. A file of another type is refused with 422 unprocessable, malware with the new 422 malware_detected; either way the file is deleted and can be uploaded again to the same slot while its URL is valid. While the scanner is unavailable, completion answers 503 service_unavailable and keeps the file: retry with the same Idempotency-Key.

• Company settings. GET /v1/companies/{companyId}/settings (and the MCP tool get_company_settings) returns a company's modules (VAT, payroll, fixed assets, intercompany), base currency, the people responsible for it (owner, controller, main accountant, auditor) and its automatic reconciliation — the company defaults and each module's overrides — with a version. Changes are patches with an optional expectedVersion (409 when the settings changed since; an approved Saga proposal must name it, as it must on every settings write): PATCH …/settings (modules, currency, responsible people — a person must belong to the company's organization and be able to read the company; reset unassigns the controller, main accountant or auditor, while the owner can be replaced but not removed), PATCH …/settings/automation (whether and how often reconciliation runs, matching tuning, autoPostOnHighConfidence, autoApprove) and PATCH …/settings/automation/modules/{module} (one module's overrides; reset hands a field back to the company default). PATCH …/settings also takes automation — the defaults and, in automation.modules, each module's overrides — so one request changes any of a company's settings together, under one expectedVersion, or none of them. Every change is audited before and after. A company without settings yet reads as the defaults with its creator as owner — the owner its first write gives it. How the settings depend on each other is in docs/agents/company-settings-interactions.md.

• Account settings and routines. GET /v1/companies/{companyId}/accounts/{accountNumber}/settings (MCP get_account_settings): the account's owner, documentation requirement, hidden, match window and its own automatic reconciliation values, with a settingsRevision. PATCH …/settings changes them as a patch (reset clears a value or lets it inherit again; 409 when settingsRevision is not the current one), and POST …/settings/actions/clear-automation-overrides returns the account to the defaults. GET …/routines lists the routines that apply to the account, with a companyRoutineVersion; POST …/routine writes the company's own routine on it and DELETE …/routine removes it, both with an optional expectedVersion (409 when the company's routine changed since), and PATCH …/routines/{routineId} (with the routine's version as an optional expectedVersion) switches an organization's or portfolio's routine on or off for the account.

• Account template type and reconciliation rules. PATCH …/accounts/{accountNumber}/settings and get_account_settings also carry the account's templateType, matchRules (GENERAL_LEDGER accounts), balanceRecon and subledgerRecon (required for SUB_LEDGER accounts), validated as the application validates them; reset clears a rule. A match-rule regex may not use backreferences, lookaround or a repeated group that itself repeats.

• Company contacts. GET /v1/companies/{companyId}/contacts (MCP list_company_contacts; ?includeInactive=true adds deactivated ones) lists the people documentation requests go to, the default recipient first. POST …/contacts adds one, PATCH …/contacts/{contactId} changes one as a patch (an empty phone removes it; an absent defaultRecipient leaves it as it is), and POST …/contacts/{contactId}/actions/deactivate and …/actions/reactivate switch one off and on — a contact is never deleted, and a change never reactivates one. One default recipient per company: making another the default moves it, and the contact that stops being the default is audited too. An email can belong to one active contact (409 duplicate_resource). The list returns a version; every contact write takes it as an optional expectedVersion (409 when the contacts changed since).

• Account template choice. GET /v1/companies/{companyId}/account-template (MCP get_company_account_template) returns the template the company uses — its own choice, or its organization's default — and the organization's templates. PATCH …/account-template chooses one of them (accountTemplateId: null follows the default again), with an optional expectedVersion from the read. Choosing changes no account.

• Intercompany counterparty links. Under /v1/companies/{companyId}/intercompany: GET …/groups (MCP list_intercompany_groups) lists the groups the company belongs to and their members; GET …/definitions (list_intercompany_definitions, ?includeInactive=true adds deactivated ones) and GET …/definitions/{definitionId} return each link to a counterparty with its reconciliation lines, the accounts on each line and the counterparty's lines to pair with. POST …/definitions links a counterparty, PATCH …/definitions/{definitionId} changes the sign convention or partial settlement, or deactivates the link (active: false) — a link is never deleted, and a deactivated one keeps its accounts. Lines: POST …/definitions/{definitionId}/lines, PATCH …/lines/{lineId}, DELETE …/lines/{lineId} (only an empty line, never the last). Accounts: POST …/definitions/{definitionId}/accounts puts an account, or one sub-ledger party or dimension value of it, on a line; PATCH …/accounts/{accountLinkId} moves it to another line; DELETE …/accounts/{accountLinkId} takes it off. Each part of an account belongs to one link: 409 conflict with a reason (intercompany_account_owned, intercompany_account_shared, intercompany_account_split_differently, intercompany_slice_owned) names the link that has it. Each link carries a version (its settings, lines and accounts) and the groups list one too; writes take them as an optional expectedVersion (409 when the link or groups changed since).

• Chart mapping. GET /v1/companies/{companyId}/standard-accounts (MCP list_standard_accounts) lists the standard accounts of the company's country. PATCH …/accounts/{accountNumber}/mapping (map_account) maps an account to one of them and DELETE …/accounts/{accountNumber}/mapping?settingsRevision= (unmap_account) takes it off; both name the account's settingsRevision (409 when it moved on). As in the application, a new standard account sets the account's reconciliation template, documentation requirement and rules, and a company that follows an account template gets the template's values for that standard account, except those it changed itself. POST …/account-mappings maps up to 500 accounts at once: a row that cannot be mapped is reported and the others are mapped. get_account_settings now names the account's standardAccount.

• Applying the account template. GET /v1/companies/{companyId}/account-template/preview (MCP preview_company_account_template) shows, account by account, what applying the company's account template would change, with the entryRevisions it read and the warnings to confirm (TEMPLATE_CHANGED, DOCUMENTATION_REQUIREMENT_REMOVED, AUTO_APPROVE_ENABLED). POST …/account-template/actions/apply applies it — overwriting values the company changed itself — and lets the company's accounts follow the template from then on: 409 when the template changed since the preview, 422 (reason: confirmation_required, with warnings) when a warning is not confirmed. GET …/accounts/{accountNumber}/template-provenance (MCP get_account_template_provenance) shows which template entry an account's values came from and which the company changed since; POST …/template-provenance/actions/restore takes one value back from the template (settingsRevision required). Apply and restore are not MCP tools.

• Scopes settings:read and settings:write for company settings. An API client reads and changes them across its organization; a person (an MCP session) reads them with the application's settings-read right. Neither scope is part of the default grant. MCP sessions may request settings:read. Company updates (PATCH /v1/companies/{companyId}) and the company lifecycle (…/actions/disable|enable|restore, DELETE) now also check the application's roles whenever a person is behind the call; API clients are unchanged.

• Close and reconciliation status (reads). Under /v1/companies/{companyId}: GET …/account-status (every account's reconciliation status for a period: balance, approved amount, deviation, status, filterable by status or account), GET …/accounts/{accountNumber}/reconciliation (one account's figures, its standing approval, adjustment lines, and whether the period can be approved now), GET …/approvals (sign-offs, including revoked ones, cursor-paginated), GET …/close-status (close percentage and close stages for a period; the vat stage is always na, VAT status is not covered), GET …/work-queue (what is overdue or awaits a decision, most urgent first), GET …/blockers (what stops automation), GET …/deadlines (Norwegian regulatory deadlines in a from/to range, default the next 90 days, at most 366) and GET …/data-freshness (when ERP data was last fetched, and what failed in the last 30 days). The same across a portfolio: GET /v1/portfolios/{portfolioId}/account-status, …/close-status and …/work-queue (year required; companies you cannot read are left out). Scope reconciliation:read; blockers, deadlines and data-freshness need companies:read. Also the MCP tools list_account_status, get_account_reconciliation, list_approvals, get_close_status, list_work_queue, list_blockers, list_deadlines, get_data_freshness, list_portfolio_account_status, list_portfolio_close_status and list_portfolio_work_queue.

• Account and sub-ledger detail (reads). Under /v1/companies/{companyId}: GET …/sub-ledgers/open-items (customer and supplier open items as of a date, with days overdue, aging buckets and totals), GET …/sub-ledgers/reconciliation (sub-ledgers against their control accounts: balances, difference, overlap and a BALANCED/BREAK verdict), GET …/settlements (which general-ledger lines were settled against each other, by a person or the automatcher), GET …/opening-balances (the lines behind an account's opening balance), GET …/accruals (the accruals on an accruals account that touch a period), GET …/reconciliation-adjustments (manual adjustment lines explaining an account-period's difference), GET …/account-activity (an account's history: approvals, comments, flags, settlements, accruals, setting changes), GET …/vouchers (voucher search) and GET …/fx-rates (the Norges Bank or ECB reference rate on a date). Scope ledger:read for open items, opening balances, accruals, vouchers and FX rates, reconciliation:read for the others. Account-scoped reads take accountNumber (with year) or the accountId the status reads return. Also the MCP tools list_open_items, get_sub_ledger_reconciliation, list_settlements, list_opening_balances, list_accruals, list_reconciliation_adjustments, get_account_activity, search_vouchers and get_fx_rate, and, MCP only behind context:read, list_routine_sources (where an account's routines come from and how they changed).

• Snapshot tools (MCP only, context:read). get_close_snapshot (close status, the top of the work queue, blockers, deadlines of the next 30 days, data freshness), get_account_snapshot (an account's settings, reconciliation, recent activity, settlements, comments, flags and documents for a period) and get_sub_ledger_snapshot (the sub-ledger reconciliation and the open items with aging at a month end) answer in one call what otherwise takes five to seven. Each part is exactly what the tool of the same name answers, within the scopes you hold: a part you cannot read is {"error": "<code>"} while the others still answer. List parts show the first rows and pagination.hasMore.

• More on existing reads, all additive:

  • General-ledger lines: filters taxCode, dateFrom/dateTo (posting date), amountMin/amountMax (signed) and voucherNo; fields subLedgerKeys, dimensionKeys, settlementStatus (open, settled, partial), settlementId, settlementType (auto, manual) and attachmentCount. Cursors issued before stay valid. The first page (no cursor) carries totals over every line the filters match: lineCount, debit, credit (as a positive number) and net; later pages have totals: null.
  • Accounts: templateType, reconciliationFrequency, documentationRequired, and owner and controller (user id and name).
  • Documents list: filters search, associationType/associationId, periodYear/periodType/period, uploadedBy and uploadedFrom/uploadedTo. A period without an association, or associationId without associationType, is 400 validation_failed.
  • Comments: mentions (userId, displayName as written into the comment, startOffset, length).
  • Companies (list, get, and the company write responses): modules (vat, payroll, assets), which modules the company uses according to its settings. A switch never set counts as VAT and payroll on, fixed assets off.

  The new reads show people as user id and name only. Settling lines, adding adjustments, marking work-queue items and ordering automation are not part of the public API, and MCP stays read-only.

• Comments, flags and accrual suggestions (reads). GET /v1/companies/{companyId}/comments, GET /v1/companies/{companyId}/flags (both newest first, cursor-paginated, with subject filters) and GET /v1/companies/{companyId}/accrual-suggestions (pending suggestions with the exact schedule accepting would create). Scope ledger:read; also the MCP tools list_comments, list_flags and list_accrual_suggestions. Writing comments and flags and deciding suggestions is not part of the public API, and MCP stays read-only.

• MCP tool schemas declare required arguments and enumerations where the operation has them (today companyId on the three tools above, periodType and itemType).

• mode: DELEGATED on GET /v1/whoami. A fourth principal mode for first-party internal services acting as the person named per request (X-Acting-User); it is not available to customers. The X-Acting-User header on any other client is refused with 400 validation_failed. Existing callers see no change.

• GET /v1/jobs lists the jobs your client submitted, newest first, with an optional status filter.

• GET /v1/organizations/{organizationId}/users/{userId}/effective-access (scope users:read) returns a user's resulting access per company.

• The specification now describes every response you can get. Creates answer 201 and asynchronous operations 202; Idempotency-Key is marked required; every schema declares its required fields and enumerations; each operation lists its error responses (401, 403, 404, 409, 413, 422, 429, 503 where they apply) and the response headers (X-Request-Id, RateLimit-Limit, RateLimit-Remaining, Retry-After, Idempotency-Replayed, Deprecation, Sunset). Problem documents document their extra fields (reason, errors, inUse, accountCodes, limit, jobId, retryAfterSeconds, requiredScope, parameter, supported), and every errors[] item has the same shape: {field, message, index?, allowedValues?}. Import amounts are documented as decimal strings; numbers are still accepted.

• Request bodies larger than 8 MiB are refused with 413 payload_too_large.

• Access-policy rules take scopeType and portfolioId on create and update, so a portfolio rule can be written and survives a rules replace. An update that would turn an existing portfolio rule into an organization-wide one (a rule with neither scopeType, companyId nor portfolioId) is refused with 409 conflict, reason: portfolio_rule_would_widen; send scopeType: ORGANIZATION to mean it.

• Documents carry associations: everything a document is attached to (company, transaction, account with its period, reconciliation run, ledger). association keeps its meaning (the first company or transaction association).

Fixed

• The settings patches require no field in the OpenAPI document. reset on PATCH …/settings and PATCH …/settings/automation/modules/{module} was listed as required although the API never needed it; absent fields stay unchanged, as documented.
• POST /v1/companies and PATCH /v1/companies/{companyId} no longer fail with 500 in production. Creating a company switched on automatic reconciliation and updating one checked its payroll mappings, both through database triggers the API was not permitted to run.
• MCP tool schemas list companyId (and portfolioId) as required on every tool that is scoped to a company or portfolio. Thirteen older tools (get_account, list_vat_terms, get_trial_balance, list_accounts, the bank and reconciliation tools, …) left it optional in their schema although a call without it is refused with companyId is required.
• Every operation that names a company, organization, portfolio or document checks access to it before anything else: a request for one you cannot reach answers the uniform 404 before its other fields are validated, and an MCP tool call that omits the id answers 400 validation_failed naming it (some tools answered 404).
• X-Request-Id is echoed only when it is 1–128 characters of letters, digits, ., _ and -; any other value is replaced by a generated id (and that id is what support can find).
• An organization that is deleted or deactivated is outside every client's and person's reach at once, including its sub-organizations and their companies.
• A write that failed after its effect could, in rare cases, run again on retry with the same Idempotency-Key; the stored response is now saved with the write itself. A retry of a request whose first attempt died mid-flight is accepted after 5 minutes instead of answering 409 idempotency_in_flight until the key expired.
• Companies: GET /v1/companies/{companyId} for a company hidden from the API answers 404 instead of 500. Two concurrent creates with the same companyNumber in one organization no longer both succeed. A company created, changed, disabled, enabled, deleted or restored through the API now reaches Accountflow's search like one changed in the application.
• Documents: a document with more than one association no longer fails GET /v1/documents/{documentId} or appears twice in lists. Download URLs serve exactly the file that was verified when the upload completed.
• Bank: listing transactions no longer fails when a transaction has neither a booking nor a value date (undated transactions come first). POST …/bank/reconciliations answers 409 conflict with reason: already_reconciled and the transactionIds when a bank transaction is already reconciled, and 422 naming the lineIds when a general-ledger line is not a current line of periodYear on the mapped account. The reconciliation summary counts periods from the company's fiscal-year start.
• Approvals: accountId lists that account's own accounting year only (a different year is 400), and a year + period filter counts from the fiscal-year start.
• Imports and corrections re-check the client, the company and the ledger when the job starts, and fail with api_client_inactive, company_unavailable or company_not_api_managed instead of uploading. Keys . and .. are refused. A 409 job_in_flight names the jobId only when you could poll that job.
• Webhooks: the host is checked on the addresses actually connected to, so a DNS answer that changes between the check and the connection cannot reach a private address.
• Data freshness and blockers: failure messages no longer carry internal ids or e-mail addresses and are cut at 1000 characters. Account activity masks e-mail addresses inside values, not only in fields named for them.
• MCP (Saga): trigger_erp_fetch and run_automatch need write access to the company; trigger_erp_fetch orders one accounting year at a time and run_automatch at most 5 years (2000 to next year); a fetching run_automatch respects the ERP's credit block and the 15-minute fetch window. create_settlement accepts only the account's own, unsettled lines of periodYear's ledger, once each, within their amount (at most 500). A mentioned user must be able to read the company. flag_item answers 409 conflict instead of an internal error when the item changes concurrently. Every delegated write refuses unknown arguments and declares its limits in the tool schema. get_account_context validates accountNumber as an account code, and an unreadable context bundle is 503. Adjustments, work-queue state and automatch orders are now audited.
• Documents: the document list now respects account-limited access. When the person a client acts for may only see some of a company's accounts, documents attached to the other accounts are left out.
• Imports and corrections: an import can no longer stay running indefinitely — an unexpected failure ends it as failed with failureReason internal_error, and one that ran out of time ends as job_expired; both are safe to re-send. Ids, keys and account codes may not contain /, {, } or whitespace (422). Importing into a year that belongs to another accounting system answers 409 company_not_api_managed. inUse, sampleErrors and failureReason only ever show your own ids. Large imports no longer delay other jobs.
• Webhooks: deleting or auto-disabling an endpoint stops its queued retries (they appear in the delivery log as dead with lastError starting cancelled:). A PATCH that repeats the current url no longer re-runs verification, and a PATCH without url works again. Receiver responses are read up to 64 KiB. IPv6 private and reserved address ranges are refused like their IPv4 counterparts.
• Access: archiving a policy, or removing a rule from it, now withdraws the access it granted. Creating or updating a policy with an organization-wide rule works again. API clients that act on behalf of a user are refused with 403 forbidden once that user is disabled or deleted.
• Documents: completing an upload is limited to the client that created it.
• MCP: tool errors no longer include internal details; an argument the tool cannot read is reported by field name.
• Imports now finish the way an accounting-system sync does: the company's last-updated timestamp moves and the usual follow-up processing runs. The import result gains an additive fetchCompletion object (status: completed, failed with a failureType, ignored, error or unreported); it never fails the import.

Earlier in this release

• 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 specification and the guides bundled as references, generated per environment at /skills/accountflow-api.zip. The Imports section now appears in the navigation of every portal page.
• Imports. Companies bound to the Api accounting system can receive their books through the API (scope imports:write). 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 (with sourceDeleted and snapshot modes to retire items). Lines carry your own id; general-ledger reads 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 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 year already holds, 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 the MCP tools list_dimensions and list_sub_ledgers) list the keys general-ledger lines and open items refer to.
• Context bundles (MCP only). Two tools, get_company_context and get_account_context, return what a company or a ledger account means: identity, standard-chart mapping and the routines the accountant registered, as compact Markdown with asOf, sources and suggestedOperations. They exist on the MCP surface only, behind the scope context:read, which only an interactive session can hold; existing connectors must re-consent to pick the scope up. A bundle that is not ready yet is a service_unavailable tool error asking you to retry, never a not-found.
• get_caller_identity answers for humans too. Additive fields userId (the person every authorization check runs as; null for system clients) and, for interactive sessions, organizationIds.
• 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, scoped to your own access. The organization directory and access administration stay off the MCP surface (users:read, access:manage, webhooks:manage are not available to interactive sessions). 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.
• Specification quality, no behavioural change: the published spec is OpenAPI 3.0.3, so nullable fields read as their declared type plus nullable: true; the token endpoint is documented as the reference's first section, with its request form, token response and the OAuth 2.0 error shape; every success response declares its full body; free-form JSON fields (job parameters and results, webhook payloads) are published as free-form objects.

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 — organization membership reads and per-user effective access.
• Access management (system clients only) — policy documents with rules, assignment and revocation, applied automatically.
• 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 for every recorded change, 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).