To improve performance and reduce unnecessary requests to Spendesk, some Public API read endpoints cache their results.

The cache duration depends on the endpoint and is given in each endpoint's reference page — for example, Get Cost Centers says "Cost centers data are cached for up to 24 hours". Depending on the endpoint, data may be cached for a few minutes, a few hours, or up to 24 hours.

What this means

When you make a normal request, the API may return a previously cached response instead of retrieving the data again from Spendesk. A recent change may therefore not appear immediately:

• Changes made through the Public API are usually reflected sooner, because the related cached responses are cleared automatically.
• Changes made directly in Spendesk (in the web or mobile app) may take longer to appear, up to the endpoint's cache duration.

Requesting the latest available data

To bypass the Public API response cache, add this header to your request:

Cache-Control: no-cache

For example:

curl --request GET \
  --url https://public-api.spendesk.com/v1/cost-centers \
  --header 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.masked' \
  --header 'Cache-Control: no-cache'

This tells the Public API to retrieve the data again instead of using the cached response. We call this a live read.

• If the request succeeds, the new response refreshes the cache: the next normal request returns this updated data.
• If the request fails, the API returns the error. It does not fall back to the older cached response, and the cache is left as it was.

🚧

Use the exact header value

Live reads are enabled only when the header value is exactly no-cache. Any other value — no-cache, no-store, max-age=0, No-Cache — is treated as a normal request and may return cached data.

Rate limits for live reads

Requests with Cache-Control: no-cache count against the normal rate limits and against an additional, stricter limit for live reads: one hundredth of the normal limit, with a minimum of 1. For example, with the limit of 1,000 requests per minute per company and credential, you can make 10 live reads per minute.

If you exceed the live-read limit, the API returns 429 Too Many Requests with a Retry-After header indicating when you can try again. Your normal requests are not affected.

If live reads are temporarily unavailable, the API returns 503 Service Unavailable. Retry later, or make a normal request.

Use live reads only when you need the latest available data — for example, right after a user changed something in Spendesk and is waiting to see it. For regular synchronization and polling, use normal requests and plan around the cache duration documented for each endpoint.

Freshness limitations

Cache-Control: no-cache bypasses the Public API response cache. It does not bypass:

• caches in downstream Spendesk services;
• existing snapshots — retrieving a snapshot of payables that already exists returns it unchanged; a live request that creates a new snapshot builds it from live data;
• other stored application state.

The response is the latest data available to the Public API and its downstream services, but it is not an absolute guarantee of immediate end-to-end freshness.

📘

MCP

The tools of the Spendesk MCP server follow the same cache durations as the endpoints they call. They do not offer live reads.