Rate limits
The fepli API limits how many requests it accepts in a given time, so one runaway script can't slow down a municipality's programme for everyone else.
The limits
| Caller | Counted per | Burst | Refill |
|---|---|---|---|
| With a token | person or service account | 300 requests | 100 requests per minute |
| Without a token | IP address | 5 requests | 5 requests per hour |
Both limits work like a bucket of tokens. Every request takes one; the bucket refills at the given rate, up to the burst size. With a token you can make 300 requests in quick succession and then keep going at 100 per minute. That's enough for a support agent working through a case or an integration syncing an edition.
The limit with a token is counted per person or service account, not per token: all tokens of the same service account share one bucket.
The limit for anonymous requests is deliberately tight. If you show offers on a public website, don't call the API from your visitors' browsers. Fetch the offers on your server, cache them, and refresh the cache every few hours. See Offers on your website.
When you hit the limit
A request over the limit is refused with the status 429 Too Many Requests. The response has no Retry-After header, so wait and retry with an increasing delay. With a token, a pause of a few seconds is usually enough: the bucket refills continuously, not once a minute.
Staying within the limits
- Request bigger pages.
itemsPerPage=200needs a sixth of the requests that the default of 30 does. See Pagination. - Fetch only what changed. Most lists take
modifiedSinceorcreatedSince. - Use references. Responses embed the name and UUID of related records, so you often don't need a second request.
- Use search to find things. One call to
/searchreplaces a lookup in five lists. - Cache public data. Offers change a few times a day at most.