Overview

The LedgerSync API gives you one REST API for your users' bank data: accounts, balances, transactions and statements, across several bank data sources. You link a bank account once and get JSON back in the same shape, whichever bank or data source is behind it.

This article explains the core concepts, the data model and the data sources behind the API.

Three Data Sources, One API

LedgerSync routes each connection to one of three sources automatically, based on the bank. You never choose a source.

• MasterCard: the widest bank coverage, with bank OAuth sign-in where the bank supports it.
• MX: a second aggregator. LedgerSync uses it for banks MasterCard does not cover, and for banks where MX offers bank OAuth sign-in.
• Statements & Checks: LedgerSync's own credential-based retrieval, for banks neither aggregator covers.

There is no source parameter when you start a connection. Routing is automatic, and each connection reports the source that served it in its source field.

Note on PDF accounts: When a user's account was set up from uploaded bank statements, its data comes back with source: "PDF". PDF accounts have no connection ID. They appear under accounts and transactions, not in a client's connections list (GET /v3/clients/{client_id}/connections), and they return no statements.

The Data Model

Everything in the API hangs off four levels of objects. Learn these once and the rest reads naturally.

• Client (cli_...): your record of one end user. You set an external_id to link it back to your own system.
• Connection (con_...): one linked bank for a Client. A single Client can have several Connections.
• Account (acc_...): an account exposed by a Connection, such as a checking, savings, credit card or loan account.
• Transaction (txn_...) and Statement (stmt_...): the financial data on an Account.

Reads are scoped to a Client: every read of connections, accounts, transactions or statements needs the Client's client_id. For example:

GET /v3/accounts?client_id=cli_...&connection_id=con_...

How Linking Works

1. Create a Client: your end user, keyed by your own external_id.
2. Start a Connection: POST to /v3/clients/{client_id}/connections with an institution_id. You receive a 202 response with an operation_id to track progress.
3. Hand off the widget: when the operation finishes, its result holds a widget_url. Open it in the user's browser, where they sign in to their bank. You never see their bank credentials.
4. Read the data: once the connection is active, store its canonical con_... ID and start reading accounts, transactions and statements.

Everything is JSON over HTTPS

No SDK is required. Send and receive JSON (statement downloads come as PDF files), authenticate with a Bearer API key, and read the X-LS-Trace-Id header on every response for support tracing.

• Live base URL: https://api.ledgersyncappv2.com/v3

Need Help?

• API Documentation: docs.ledgersyncappv2.com
• Email: support@ledgersync.com

Related Articles

• How to Request Live (Production) API Access
• LedgerSync API: Authentication & API Keys
• LedgerSync API: Getting Started (Quickstart Guide)