Exact Online
The token expires in ten minutes and you may not refresh it
Exact Online is the connection where the honest answer is architectural rather than practical. Its token rules make refreshing on demand impossible, so the refresh has to run on a schedule whether or not anybody is calling.
Access token
10 minutes
Refresh floor
570 seconds
Rate budget
60 / minute, per administration
What gets asked for
Four jobs, in the order people want them
Recognise the caller among the accounts
One filtered read on the number, using a token that is already in memory rather than one fetched on the spot.
Read the invoice or order in question
So the agent can answer about the specific document instead of promising that somebody will look into it.
Check whether something is paid
Before the agent commits to anything. This is the read most worth getting right, because being wrong about money is expensive twice.
Log the call for finance
Queued for after the conversation, so the rate budget is spent on reads while the caller is still there.
The constraint that bites
You cannot refresh a token when you need it
An Exact Online access token is valid for ten minutes. The obvious design is to refresh it the moment a call needs one. That design does not work: Exact does not allow a new access token to be requested more than once every ten minutes, with a documented minimum of 570 seconds between requests. Refresh on demand and the second caller of the minute gets an error instead of an answer.
So the refresh runs on a timer in the background, and the call path only ever reads the token that is already there.
Exact allows no more than ten errors per API key, per user, per company, per endpoint, per hour. Exceed it and the key is blocked, and the block lifts by itself an hour later. A voice agent that retries a failing lookup is the fastest way to reach that ceiling, and it would do so during exactly the incident you least want to extend. It is one more reason a tool call on our platform gets one attempt rather than three.
Numbers
- Rate limit
- 60 calls / minute per company
- Daily limit
- 5,000 calls / day per company
- Access token
- Valid 10 minutes
- Refresh floor
- 570 seconds between token requests
- Error ceiling
- 10 errors per key, user, company, endpoint, hour
In practice
A recognised call, end to end
token service · background, independent of traffic
[auth] refresh · 570s floor respected · ok 08:41:00
inbound +31612345678 t+0.00s
[token] read from memory · 6m remaining t+0.00s
[eol] GET /crm/Accounts?$filter=...
[eol] 200 · 1 account · 520ms t+0.52s
[eol] GET /SalesInvoices?$filter=...
[eol] 200 · 1 open invoice · 480ms t+1.00s
[agent] "The one from 12 August is open." t+1.08s
rate budget used 2 of 60 per minute
tokens fetched 0 · that is the pointWhat gets built
A token service, then everything else
The first component is not the lookup. It is a small service that holds the current access token, refreshes it on a schedule well inside the ten-minute window, and hands it out to everything else. Once that exists the rest is ordinary: filtered reads on the call path, writes queued for after the call, and a circuit breaker that stops calling Exact entirely once errors start, so the hour-long block never happens.
refresh every 8 minutes, on a timer
floor 570s minimum between requests, enforced
call path reads only · never triggers a refresh
on error circuit opens after 3 failures in 10 minutes
// The circuit breaker exists because of the error ceiling:
// 10 errors buys a one-hour block, and a retry loop
// reaches 10 faster than a human can notice.What we need from you
Four things, and one of them is a person
The app registration
Client id and secret in your environment, with the redirect that belongs to them. The credentials sit behind the endpoint we post to, never on our platform.
Which administrations
The rate budget is counted per administration and does not pool. Serving four administrations from one integration is four budgets, not one shared one.
Somewhere the token service can run
It has to stay up when nobody is calling, because the timer does not care whether the phone rings. This is the one piece that cannot be serverless-on-demand.
Who to tell when the key is blocked
A block lasts an hour and clears itself. Somebody should know that before they start restarting things and make it worse.
Questions we get first
Can the agent read Exact live during a call?
Yes, for a filtered single-record read, and comfortably inside the thirty seconds a tool call gets. What it cannot do is fetch a token first, which is why the token service exists.
What happens when Exact is slow or down?
The tool call times out, the agent is told the lookup failed, and it says so and offers a callback or a transfer. It does not invent a balance. Fail closed is a platform-level position here, not a per-integration choice.
Does the rate limit apply per company?
Yes. Sixty calls per minute and five thousand per day are counted per company, which matters if you serve several administrations from one integration, because the budget does not pool.
Who owns the Exact app registration?
You do. The credentials sit in your environment behind the endpoint we post to, so the token service is yours as well, whether we build it with you or you build it yourself.
Going deeper
The two articles underneath this page
Thirty seconds, one attempt
Why a tool call gets a single try, which lookups may hold up a conversation, and what the agent says while it waits.
Thirty seconds, one attemptKnowing who is calling before they say so
The number arrives in E.164 and your CRM holds six other formats. Normalisation, caching, and shared numbers.
Knowing who is calling before they say soBring us the awkward one
Send the system, its API documentation and one call you want to automate. On the intake call we will tell you whether the hard part is the code or the configuration, and which of the two sets the date.