What is Chift's Data Layer, and why should your SaaS use it?

Your product calls an accounting API. The source system is slow, rate-limited, or simply unavailable. Your user waits. Your integration looks broken.

This is the ceiling of the traditional live-request model. The more you scale, the more it costs you. Chift's Data Layer was built to remove that barrier.

The standard Unified API

By default, every call to a Chift unified endpoint is transactional: Chift forwards the request to the third-party accounting system in real time, normalises the response, and returns it. The customer's data never sits inside Chift. Every read is a live round-trip.

For most use cases, this is exactly what you want: real-time status, instant write-backs, the freshest state of a record.

But the model has limits. When your product needs to paginate through years of journal entries, pull large sets of invoices across multiple folders, or run analytical queries at scale, you are suddenly at the mercy of the source ERP's speed, availability, and rate limits. And no matter how good your integration is, you cannot outrun a slow upstream system.

What is Chift's Data Layer?

Chift's Data Layer is an alternative read mode for the unified accounting API. Instead of querying the source system live, 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.

The key point: the API surface is exactly the same. You keep calling the same Chift endpoints, with the same parameters, and get the same response shape. The only change is a single request header: x-chift-datalayer: true. That header tells Chift to serve the response from its Data Layer store rather than from the live source.

This means you can adopt the Data Layer without rewriting a single line of your integration code.

How the sync works

There are two layers here, and it's worth keeping them straight.

First, Chift keeps its Data Layer store in sync with the source accounting system in the background, on a cadence we configure per connection. You don't run this and you don't manage it. When a refresh finishes, we fire the account.datalayer.refresh_executed webhook, so you always know the moment fresh data is ready. If all you need is fast reads, you stop here: call the same endpoints with x-chift-datalayer: true and you're done.

Second, if you keep your own copy of the data, a reporting store, an analytics database, an AI context store, you'll want to sync that copy from the Data Layer without re-reading everything each time. The Data Layer is built for this, and the loop is simple:

1. Initial full load. The first time, page through each resource with no updated_after filter and upsert every record into your store. This seeds your dataset.

2. Incremental reads. On each cycle after that, read each resource with updated_after set to the start of your previous fetch. You get back only the records created or changed since, and you upsert them. Trigger this off the refresh_executed webhook so you read exactly when there's something new.

3. Periodic full fetch. Incremental reads can't surface deletes, a deleted record simply stops appearing. So on a slower cadence, weekly is a good default, do a full read with no filter and reconcile: anything in your store that's absent from the full set has been removed at the source. The account.datalayer.data_deleted webhook reports removals in real time, and the weekly pass catches anything you missed.

Why use the Data Layer: four concrete benefits

1. Fast, consistent read latency

Response times no longer depend on the load or availability of the source accounting system. Whether the ERP is slow, under maintenance, or throttling requests, your reads return at the same speed. This matters especially for reporting dashboards and AI-powered workflows that need predictable performance.

2. Built for large datasets, reporting, and AI

Paginating through years of journal entries, pulling hundreds of invoices in one session, computing over long historical windows: these patterns put real pressure on live APIs. The Data Layer is built for them. Heavy filtering, date ranges, multi-folder queries, all served from a store optimised for reads. That's exactly what reporting tools, financial analytics products, and AI agents need, the data density and response consistency to work over large volumes without overloading the source.

3. Decoupled from source-system rate limits

Source accounting systems can impose rate limits. The more users you add, the more calls you make, the more likely you are to hit those limits. With the Data Layer, your read traffic is decoupled from the source. Only the sync touches the source system on each cadence, not every user request.

4. Get notified the moment new data lands

You don't have to poll the Data Layer to find out when something changed. Four webhooks fire around each refresh:

• account.datalayer.refresh_initiated when a refresh starts.
• account.datalayer.refresh_executed when it finishes, whether it succeeded or failed.
• account.datalayer.data_changed telling you which resources changed in that refresh.
• account.datalayer.data_deleted telling you which records were removed.

Live API or Data Layer? Use both.

Unified API (default)

• Source of reads: Live, from the source system
• Freshness: Always latest
• Response time: Depends on the connector
• Heavy queries / history: Limited by the source
• Writes: Go straight to the source

Data Layer (x-chift-datalayer: true)

• Source of reads: Chift's Data Layer store
• Freshness: As of the last sync
• Response time: Fast and consistent
• Heavy queries / history: Designed for it
• Writes: Still go straight to the source but eventually consistent in the database

Built with these products in mind

Use the live API for write-then-read flows, where up to date data is crucial, and single-record lookups. Use the Data Layer for analytics, reporting, historical pagination, and AI-driven data processing.

The Data Layer is for any product that needs to read a lot of financial data, fast and reliably. A few examples:

Reporting and analytics tools. Dashboards that compute over months or years of accounting data need predictable response times and the ability to paginate through large sets without hitting source rate limits. That's the core pattern the Data Layer is built for.

Banks, neobanks, and lenders. Products that assess a business's financial health need broad, dependable access to accounting history, for affordability checks, risk scoring, credit decisions, or ongoing monitoring. Reading a lot of history at once, on demand, is exactly where a live source system becomes a bottleneck. The Data Layer removes it.

Financial management and cashflow tools. Anything that aggregates and analyses a customer's full financial picture benefits from a store optimized for heavy reads, rather than making a live round-trip to the source for every query.

AI-powered products and agents. Agents reasoning over financial data need dense historical context served fast and consistently. The Data Layer gives them that depth without overloading the source, which makes it a natural fit for AI, though far from its only use.

If your product reads financial data at scale, and especially if slow or rate-limited source systems are getting in your way, the Data Layer is for you.

What's covered today

The Data Layer currently covers the Accounting unified API, further verticals like banking and POS will be soon available. Available resources include: folders, chart of accounts, journals, journal entries (with lines), invoices (with lines and payments), partners, VAT codes, and book years.

Get started with Chift's Data Layer

• Same API surface, no integration rework required
• Per-request opt-in with a single header
• Configurable sync cadence per connection
• Webhook events to react to each refresh
• Multi-tenant isolation with row-level security
• Built for reporting, analytics, and AI agents

Curious to see how the Data Layer can fit your product? Read the full documentation or book a demo with our team.