Data layer overview

The data layer is an alternative way to read unified data through Chift. Instead of querying the source accounting system live on every request — the way the unified API normally works — your reads are served from a copy of the data that Chift maintains on its own infrastructure and keeps in sync with the source in the background. This is the perfect solution for reporting use cases or for AI agents to compute a lot of data and context. The API surface is exactly the same. You keep calling the same unified endpoints with the same parameters and get the same response shape. What changes is where the answer comes from, and you choose that per request by setting a header.

​

How it differs from the unified API

By default, every call you make to a Chift unified endpoint is transactional: Chift forwards the request to the third party system in real time, normalises the response, and returns it. When you send the request with the x-chift-datalayer: true header, the same call is served from Chift’s data layer store, which is populated by a sync that runs in the background. The source system is contacted by the sync, not by the request. Because the choice is made per request, the same connection can serve both live and data layer reads side by side. If you need a record back the instant you’ve written it, simply omit the header on that read; if you’re paginating through history, send it.

​

When to use the data layer

The data layer is the right choice when you want:

• Fast, consistent read latency that doesn’t depend on the load or availability of the source accounting system.
• To page through large amounts of historical data (entries, invoices, partners) without hitting the source on every page.
• To run heavier read patterns — filtering, date ranges, multiple folders — at a higher rate than the source would comfortably allow.
• To decouple your read traffic from the source system’s rate limits and downtime.

The default unified API remains the right choice when freshness matters above all (status checks, write-then-read flows, real-time UIs), when traffic is modest, or when the data you need isn’t yet covered by the data layer.

​

What’s covered today

The data layer currently covers the Accounting unified API only. Within that scope, the standard accounting resources are available:

• Folders
• Chart of accounts (ledger accounts)
• Journals
• Journal entries (and lines)
• Invoices (and lines, payments)
• Partners (clients and suppliers)
• VAT codes
• Book years

​

How freshness works

The data layer is populated by a sync attached to the connection. The sync runs on a defined cadence and writes the records it pulls into the data layer store. How much it pulls on each run depends on the kind of entity:

• Time-series entities — journal entries and invoices — are synced incrementally. Each run pulls only the records created or changed in the source since the previous run, plus a configurable lookback window that re-pulls recent history to catch late edits and backdated changes. This keeps each run fast even as history grows.
• Reference data — folders, chart of accounts, journals, partners, VAT codes and book years — is fully re-synced. These sets are small and change rarely, so every run refreshes them in full rather than tracking deltas.

A few things to know:

• Reads with the header always reflect the last successful sync. If the source has changed since the last sync ran, those changes are not yet visible through the data layer.
• Reads without the header are always live, so a write-then-read flow that needs the freshest state simply skips the header on the read.
• The sync cadence is configurable per connection and is agreed with your CSM/SE when the feature is enabled — see Activating the data layer.

​

Refresh webhooks

You can subscribe to webhooks to know exactly when a data layer refresh runs, so you can react when fresh data becomes available (for example, kick off downstream reporting jobs once a refresh completes). Two events are emitted, once per consumer, around each refresh:

• account.datalayer.refresh_initiated — sent when a refresh starts for a consumer.
• account.datalayer.refresh_executed — sent when the refresh finishes for that consumer, whether it succeeded or failed.

Both carry the standard webhook attributes (accountid, consumerid, created, …) plus the connectionid of the connection being refreshed, the api the sync refreshes (e.g. Accounting), and a scope describing the part of the source the refresh covers (the scope shape depends on the API). See Webhooks for the full payload format and how to verify the signature.

​

Security and isolation

The data layer is multi-tenant by construction. Every record stored on Chift’s side carries the identifiers of the customer it belongs to — the consumer, the connection and, for accounting, the folder. We will propose in the future a hybrid architecture for this use case as well. Next: Activating the data layer walks through how to enable it on a connection and how to use the header in your requests.