Caching
Business Central keeps a data cache on each application server node, and Microsoft synchronizes that cache between nodes on a schedule rather than instantly. This article describes when that affects your integration and how to read around it.
When cache consistency is not guaranteed
As described in API Key, you can link more than one Entra App to an API key to increase throughput. When you do, requests might be load balanced by Microsoft across multiple Business Central nodes.
Each node has its own data cache. Microsoft synchronizes these caches between nodes, but only every 30 seconds:
Business Central synchronizes caching between Business Central Server instances that are connected to the same database. By default, the synchronization occurs every 30 seconds.
— Microsoft, Optimize SQL data access: Server data caching
The consequence: when your API key has more than one Entra App, a mutation (POST, PUT, PATCH or DELETE) followed by a read (GET) within 30 seconds is not guaranteed to return the mutated data. The GET may be served by a node whose cache has not yet received the change.
With more than one Entra App linked to your API key, cache consistency between a mutation and a following GET is only guaranteed once 30 seconds have passed, or when the GET bypasses the cache as described below.
Bypassing the cache
If a GET absolutely must return fresh data, add the header x-server-cache-id: -1 to the request:
This bypasses the application server cache and reads straight from the database. It worsens the performance of that request considerably, so use it only for the reads that need it, not as a default on every GET.