Apideck
Apideck · Architecture
Schedule a demo
Architecture

Where the data lives

The downstream accounting system is always the source of truth. Apideck stores no entity data — no invoices, no contacts, no ledger entries — so every call is real time and nothing can go stale.

Source of truth

We're a pipe, not a warehouse. By design.

A cache in the middle is a second thing to be wrong. Apideck holds credentials and configuration; the ledger stays where your customer keeps it.

Your app
makes API calls
Apideck
tokens + config only
QuickBooks · Xero · NetSuite
your data · source of truth

Every read fetches live. Every write goes straight through. There is no copy of your customer's ledger in the middle.

0
entity records stored by Apideck
real time
every read, straight from the system
direct
every write, no queue in between
What we hold

The short list, and the long one.

Apideck stores
  • OAuth tokens and API keys, encrypted, refreshed on schedule
  • Connection metadata — which consumer authorized which connector
  • Consumer configuration and custom field mappings
  • Request logs (see the Logs tour)
Apideck stores zero of
  • Invoices, bills, payments, journal entries
  • Contacts, customers, suppliers
  • Ledger accounts or any balance
  • Employees, or anything else from a unified model
One exception
A small number of connectors run on-premises rather than behind a vendor cloud API — QuickBooks Desktop is the only one today. Because the data never passes through a vendor API, Apideck may need to temporarily store your data as part of the sync. What's held that way is transient and exists only to complete the sync, but it is a real exception to pass-through, so the same notice appears on the connector page before you enable it. Every cloud connector — the overwhelming majority of the catalogue — stays fully pass-through.
Your call
If you need a local cache or a data warehouse, that's yours to build on top of the API responses — and it's a legitimate choice for reporting workloads. Apideck just won't do it behind your back, so you always know which copy is authoritative.
Zero data retention, in full
Interactive

One model, every connector. Even these two.

Exact Online and AFAS return different field sets, different id formats, different notions of what a ledger account even is. Pick a unified field to see where it lands in each.

Unified model
exact-online logoExact Online9 fields
{
"id": "83d72837-fc04-45fc-a4fc-002dde2d116a",
"code": "232009",
"sub_type": "Accumulated depreciation",
"name": "Outillage : amortissements",
"description": "Outillage : amortissements",
"updated_by": "fdb808a7-0644-4628-b836-9afb25ef7514",
"created_by": "fdb808a7-0644-4628-b836-9afb25ef7514",
"created_at": "2024-10-07T04:38:22.423Z",
"updated_at": "2024-10-07T04:38:22.423Z",
}
afas logoAFAS13 fields
{
"id": "0100",
"display_id": "0100",
"nominal_code": "0100",
"code": "0100",
"name": "Bedrijfsinventaris",
"description": "Bedrijfsinventaris",
"classification": "other",
"type": "expense",
"tax_type": " 5",
"status": "active",
"active": true,
"created_at": null,
"updated_at": null,
}

Same call — GET /accounting/ledger-accounts — against two ledgers that share nothing architecturally. The highlighted fields are the unified model: always present, always the same names and types. Each system also returns its own extras, mapped into the same schema and the same envelope, so your integration code never branches on which connector answered.

Accounting API referenceConnector APIs change; the unified model absorbs it.
The consequence

Write once, run on the next one too.

quickbooks logoQuickBooksnetsuite logoNetSuitexero logoXerosage-intacct logoSage Intacctexact-online logoExact Onlinefreshbooks logoFreshBooksafas logoAFAS Software+41 more
One request shape. One response shape. The service id is the only difference.