Changelog

​

Teammates can use LedgerSync in Claude and ChatGPT

• Each person sees only what they see in the LedgerSync app: an employee sees the clients assigned to them, an administrator sees the whole firm.
• A client an employee creates through the AI is assigned to them, as in the app.
• The firm owner gets an email each time a teammate connects.
• Changing or resetting a password now disconnects only that person’s AI connections. The firm owner’s password change no longer disconnects teammates.
• Sub-account (firm) logins and their employees, and logins with access days and hours, cannot connect yet. Client logins and support sessions cannot connect.
• Only the firm owner links the desktop app. Teammates can check whether it is connected.

​

A simpler AI connector guide for LedgerSync customers

• A firm new to LedgerSync signs up in the LedgerSync app first (ledgersyncappv2.com/sign-up), then connects Claude or ChatGPT.
• The setup pages keep their title and progress bar at the top while you scroll, and the setup videos open over the page.
• The Claude Team or Enterprise and ChatGPT Business, Enterprise or Edu steps are now at the top of each setup page.

​

Sign in to the AI connector with your LedgerSync app login

• Firms that use the LedgerSync app sign in with their normal LedgerSync username or email and password, plus their two-step code if they use one. No developer portal account and no email to support.
• New firms create their LedgerSync account on that page: Create account, the sign-up form, then the order page. Our team reviews each new firm once. Until then the connector answers the new code firm_under_review when asked to connect a bank. Clients can be added.
• Only the firm owner can connect for now.
• Approved developer accounts type their developer portal email on the LedgerSync page, which sends them to the developer portal sign-in. An application still waiting for its first approval cannot connect yet.
• Connections made before this change keep working.
• The portal’s AI sign-up page (/start/ai) now sends new firms to the LedgerSync app sign-up.

​

See which banks need the LedgerSync desktop app, and link it from Claude and ChatGPT

• On institutions (GET /v3/institutions and GET /v3/institutions/{id}): true when LedgerSync reaches the bank through FDE and needs the desktop app to refresh it. Omitted when unknown.
• On connections (GET /v3/connections/{id} and GET /v3/clients/{client_id}/connections): on FDE connections only, omitted for other sources. When true, the desktop app must be open and connected on the firm’s computer for a refresh to run.

• ledgersync_get_desktop_app_status says whether the desktop app is linked and connected right now, with the Windows and Mac download links and the setup steps.
• ledgersync_pair_desktop_app links the app with the 7-character code it shows. It replaces any computer linked before, so the AI asks the user to confirm first. Each account gets 10 tries an hour and 20 a day.
• Bank search results and connections in the connector mark the banks that need the app.
• New codes for linking: pairing_code_invalid, desktop_app_session_closed, desktop_service_unavailable and pairing_rate_limited.

• A refresh FDE stops because the bank needs the desktop app and the app is not connected fails at once with desktop_app_required, and the connection reads requires_action with the same code. A refresh stopped while waiting for the choice of whether to use the desktop app fails with desktop_app_route_choice. Neither reached the bank, so neither counts against the daily refresh budget.
• When FDE asks at the start of a refresh whether to use the desktop app, a working FDE connection no longer shows requires_action with mfa_required for that moment. It stays active, and no webhook fires for the question.

​

New firms can sign up for Claude and ChatGPT in a few minutes

• The first charge is one month after the card is added.
• We review each firm once, within 2 business days, and email the answer. A sign-up we do not approve, or one that closes before its review, is not charged.
• The firm can add LedgerSync to Claude or ChatGPT while it waits; it starts working as soon as the firm is approved.
• On the live connector, Claude and ChatGPT now explain in plain words what a new firm still needs to do, with a link to the right page.
• Developers building on the API keep the usual path: a sandbox request, then the Live application and payment.

​

Use LedgerSync in Claude and ChatGPT

• Live: https://api.ledgersyncappv2.com/mcp. Sandbox: https://api-sandbox.ledgersyncappv2.com/mcp.
• Sign in with your developer portal account. Live needs the same approval and payment as live API keys; existing LedgerSync app customers are linked, not charged again.
• The portal’s new Connected apps page lists the AI apps connected to your account and disconnects one at once.

​

Refreshes of MX and FDE connections now finish

• MX and FDE refresh operations reach a real verdict. They used to record no accounts to wait on, so every one ended failed with refresh_timed_out after 90 minutes, whatever happened at the bank.
• MX refresh webhooks are sent for client connections. account.refresh.completed and account.refresh.failed were never sent for an MX connection that belongs to a client, which is every MX connection made through the API. They are now.
• An MX refresh that finds nothing new still finishes. MX sends LedgerSync no notice when a sync brings no new or changed transactions, so LedgerSync now asks MX once the sync is over and reports it. Expect the verdict about three minutes after the call.
• An FDE refresh the bank answers with a security question fails at once with mfa_required, instead of waiting out the timeout. Send the user a fix link from POST /v3/connections/{id}/reauthorize. Any other refusal fails at once with source_internal_error, with the FDE status in source_diagnostic_code (for example FDE-UPDATED_ERROR). No webhook fires for either; read the operation.
• FDE connections report last_refreshed_at. It was always null on FDE connections. Their created_at and updated_at, which follow it, fill in too.
• Sandbox refresh operations finish too. On sandbox they never matched their results and always timed out.
• An earlier sync can no longer answer your refresh. A sync result that reached LedgerSync before your call, but was still being processed, could close your refresh with that older data. Only a result that arrives after your call answers it now.

​

Statement downloads work again

​

Connection status and webhooks now agree

• MX connections read their real status. The read endpoint used to report any unhealthy MX connection as disconnected. It now follows MX’s own member status, the same one the webhooks report: MX PREVENTED (too many failed sign-ins) and DENIED read requires_action with credentials_invalid, MX DISCONNECTED and CLOSED read disconnected, and a healthy or still-syncing member reads active. Expect some MX connections to move from disconnected to their real status.
• The reason matches the status. A connection.requires_action for MX PREVENTED used to carry institution_unavailable with is_user_actionable: false. It now carries credentials_invalid, actionable. An MX-locked account is the one deliberate exception: requires_action with account_locked_by_institution and is_user_actionable: false, because the user acts at the bank. See Errors for the MX codes behind each error.
• Connection events name the client. data.connection.client_id is now present on status-change events whenever the owner can be resolved, and the key is omitted, never null, when it cannot.
• Deleting a connection sends connection.disconnected, as the testing guide already described.
• Status changes found by the scheduled daily refresh now send webhooks. A connection that recovers on its own after connection.failed sends connection.active. One exception remains: a Finicity MFA challenge on an existing connection reads requires_action on GET without an event.
• A new MX connection is named by a webhook. When a first MX link connects, or the bank rejects it, a connection.* event now carries the canonical con_MX_... id. Before, only the initiate connection.requires_action under the placeholder id fired, so an MX link that connected without an MFA step, or failed outright, had to be found by listing the client’s connections.

​

Card terms, account masks and retracted transactions

• liabilities appears only on liability accounts, such as credit cards, lines of credit, loans and mortgages. It no longer appears on checking, savings or investment accounts, even when the bank reports a figure there. Identify cards by type: credit_card; loans and mortgages carry the object too.
• MX now reports the statement balance. It was dropped before, so every MX statement_balance was null. It fills in as each MX account next syncs.
• Card terms refresh on the scheduled daily refresh, not only when a refresh is triggered.
• mask is now filled for MX, portal (FDE) and uploaded-statement accounts, as at most the last 4 digits of the account number. It used to be null for all three.
• GET /v3/transactions/{id} returns 404 for a Finicity transaction the source retracted. The list never returned those; the single read now agrees. If you stored such an id, treat the 404 as “removed”.

​

Webhook subscriptions now report delivery health

{
  "id": "whk_7c1e4a9b83d24f6ab05e2f8c91d3a640",
  "url": "https://yourapp.com/webhooks/ledgersync",
  "status": "active",
  "last_success_at": "2026-09-14T11:43:02Z",
  "last_failure_at": "2026-09-12T21:08:05Z"
}

​

Credit-card terms on the Account

{
  "id": "acc_FINICITY_84213",
  "type": "credit_card",
  "current_balance": -14381.66,
  "liabilities": {
    "credit_limit": 65000.00,
    "available_credit": 50596.54,
    "statement_balance": -14381.66,
    "minimum_payment": 143.00,
    "payment_due_date": "2026-09-24"
  }
}

​

Fetching a single transaction works on every source, and accounts now say how far back they go

{
  "id": "acc_FINICITY_84213",
  "type": "checking",
  "oldest_transaction_date": "2026-05-28"
}

​

Account type is now guaranteed, and balances are signed consistently

​

Refresh now pulls transactions, and its operation actually finishes

• Transactions are pulled and last_refreshed_at advances, so re-reading GET /v3/accounts after the webhook shows what you would expect.
• The operation reaches a terminal state. A refresh is one aggregation at the bank but reports per sub-account, so the operation turns succeeded or failed once every account on the connection has reported - and resolves on its own if the events never arrive, so polling always terminates.
• Partial failures are reported as failures, not as partial successes. If the aggregation ran but one account did not come back, you get refresh_partially_failed with a per-account breakdown in error.accounts[], so branching on status alone cannot quietly ship a connection that is missing an account’s transactions.
• New error codes: refresh_partially_failed, refresh_timed_out, refresh_outcome_not_observable, no_refreshable_accounts.
• Refresh now has a daily budget separate from the request-rate limit, since each one is a real aggregation at the institution. Over it, the call returns 429 rate_limit_exceeded without touching the bank.
• estimated_seconds on the 202 was raised from 10 to 120 to match how long a refresh actually takes. It is a best-effort floor, not a deadline.

​

Reauthorize (fix) a broken connection in place

• Returns a reauthorize action with a hosted reauth_url; redirect the end user there to re-enter credentials or re-consent at the institution, then wait for connection.active (or connection.failed).
• ID preservation depends on the provider and whether the repaired login and accounts match the stored connection. Starting another Finicity Full Connect session can also reuse an existing bank login; use that flow to add accounts, and verify canonical IDs afterward.
• Available for FINICITY, MX, and FDE. Uploaded-statement (PDF) sources are read-only and have no connection to reauthorize.

​

Check images are now readable from the API

GET /v3/accounts/{account_id}/checks
GET /v3/accounts/{account_id}/checks/{check_id}
GET /v3/accounts/{account_id}/checks/{check_id}/download

• Requires the new read:checks scope. Existing keys don’t have it — tick it on a new key in the portal, or PATCH /v3/api-keys/{id} to widen the key you already have without rotating its secret.
• FDE-only. Non-FDE accounts return an empty list rather than an error, so you can call this uniformly across sources.
• There is no back image — LedgerSync captures the front of a check only, so there is no side field.
• Bank-reported fields and ocr.* are kept separate, so you can always tell what the bank said from what OCR read off the paper.
• The sandbox Ledgersync Bank (ins_a7397a8d0656e1b7) returns real check images, so the whole flow is testable end-to-end.

​

On-demand refresh now works for MX connections

• Completion is asynchronous — listen for the account.refresh.completed webhook (or account.refresh.failed on terminal failure), then re-read GET /v3/accounts for the updated balances and transactions.
• All three connectable sources (Finicity, MX, FDE) now answer /refresh uniformly, so you no longer need to special-case MX.

​

PDF: a read-only fourth data source

• Read-only: PDF isn’t linked through the widget and never appears under GET /v3/connections — a PDF account’s connection_id is null.
• Exposed on GET /v3/accounts and GET /v3/accounts/{id}/transactions. Statements aren’t served for PDF accounts.
• Everything else — pagination, filtering, the response shape — reads exactly like an aggregator source.

​

Cursor pagination on all list endpoints

• Keyset (seek) based, so it stays correct even as rows are added or removed between pages — no skipped or double-counted items.
• limit defaults to 100 (max 500; higher values are capped, not rejected).
• Cursors are opaque and query-scoped — reusing one against a different account, filter, or date window returns 400 invalid_request.

​

Extract transactions from a bank-statement PDF

• Customer-level and standalone: no client_id, and the upload never attaches to a connection, account, or stored statement.
• Async: returns 202 with an operation_id; poll GET /v3/operations/{id} (most statements finish in under a minute). The result carries kind: statement_extraction. There’s no webhook for this one — polling is the completion signal.
• PDF only, up to 30 MB (larger uploads are rejected with 413). Requires the write:statements scope. Per-customer concurrency and daily budgets apply on top of the standard rate tiers — exceeding them returns 429.