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.

	Unified API (default)	Data layer (x-chift-datalayer: true)
Where reads come from	Source unified system, live	Chift’s data layer store
Freshness	Always the latest state of the source	As fresh as the last sync
Response time	Depends on the source system	Fast and consistent
Heavy queries / pagination over history	Limited by the source	Designed for it
Writes (create / update)	Go straight to the source	Still go straight to the source — the data layer is read-only
API surface used	Same unified endpoints	Same unified endpoints
Opt-in level	Default	Per request, via header

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)
• Book years

How freshness works

The data layer is populated by a sync attached to the connection. The sync runs on a defined cadence, pulls the records that have changed in the source system since the previous run, and writes them into the data layer store.

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.