Data layer overview

Documentation Index

Fetch the complete documentation index at: https://docs.chift.eu/llms.txt

Use this file to discover all available pages before exploring further.

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 casese 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)
• 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.

​

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.