Rate limits

The API allows 100 requests per minute, per endpoint. Because the counter is per endpoint, calls to /v1/classes do not consume the budget of /v1/workshops. A page that loads classes, workshops, lecturers, and places gets 100 calls per minute on each. Treat 100/min per endpoint as the ceiling for your whole integration, and design to stay well under it. Exceeding the limit returns 429:

{
  "statusCode": 429,
  "error": "Too Many Requests",
  "message": "Rate limit exceeded: up to 100 requests per minute per endpoint."
}

Every response includes these headers:

Header	Meaning
`X-RateLimit-Limit`	Maximum requests in the current one-minute window.
`X-RateLimit-Remaining`	Requests remaining in the current window.
`X-RateLimit-Reset`	Unix timestamp in seconds when the window resets.

Use X-RateLimit-Reset when scheduling a retry after 429.

Staying under the limit

Cache reference data. Lecturers and places change rarely. Fetch them once per page load — or once per hour — instead of once per event. Request wider ranges. One call for a whole month costs the same budget as one call for a single day. The range is capped at 366 days, so a long backfill is a handful of calls, not hundreds. Skip capacity when you can. includeCapacity is more expensive. Ask for it only where you actually show live availability. Use bulk grants. Bulk credits and passes handle 100 clients in one request instead of 100.

Handling 429

Back off and retry. The window is one minute, so a short exponential backoff starting around a second recovers quickly. Read endpoints are safe to retry. For the credit and pass endpoints, a 429 means the request never reached the grant logic, so retrying is safe there too — but never retry blindly on a 500, which may have applied.

Zenamu API

Objects

Endpoints

Staying under the limit

Handling 429

​Staying under the limit

​Handling 429

Staying under the limit

Handling 429