Skip to main content
Limits are counted per API key, not per IP. Two integrators behind the same proxy do not penalise each other. The general quota is configurable per key: if your integration needs more, ask the organiser and they can raise it from the dashboard.

​
Headers

Every response carries:
Once exhausted, the response is 429 with retry-after in seconds:
Do not invent your own wait: use the retry-after value. The server knows exactly when your quota frees up.

​
How not to hit the limit

POST /tickets accepts up to 500 tickets per call. Loading 5,000 tickets is 10 calls, not 5,000. With a write quota of 20 calls per minute, that is the difference between half a minute and four hours.
Lists accept limit=200. Walking 10,000 sales becomes 50 calls instead of 200.
Do not pull the whole history on every pass. Use updated_since and since as explained in Pagination.
Checking ticket state every second does not give you fresher information than exists: terminals sync in batches. Every 30 seconds is more than enough during the event.

​
Operational note

The counter lives in the memory of the process serving the request. On a single-instance deployment — the usual case — it is exact. If the event is served from several instances, the effective quota may be somewhat higher than the nominal one. Never lower, so there is nothing you need to do about it.