Docs/API Usage & Limits

API Usage & Limits

What actually bounds the places and competitions APIs: pagination caps and response caching. No key, no rate limiting today.

StudentSuite Team · 2026-10-27 · 2 min read

Both Places API and Competitions API are public, unauthenticated, read-only endpoints. This page is the honest answer to "how much can I call this" - what's actually enforced, not what might be assumed.

No API key, no rate limiting

Nothing throttles requests by IP or client today

Neither endpoint requires a key, and neither currently enforces a requests-per-minute style limit. What bounds them instead is pagination and caching, below. If that ever changes (a key requirement, a 429 response), it will show up on the changelog and this page gets updated alongside it - don't build something that silently breaks if a limit is added later.

Pagination caps

The real limit is response size, not request rate

/api/places: defaults to 100 rows, hard-capped at 500 regardless of what limit you pass.
/api/competitions: defaults to 50 rows, hard-capped at 200.

To pull a full dataset, page through with offset at the max limit rather than requesting everything at once.

Response caching

6 hours - the real reason you rarely need to poll fast

Both endpoints set a Cache-Control header with a 6-hour max age. The underlying datasets change a few times a week at most, so polling more often than that gets you the same data, served from cache either way.

Building something that hits these a lot?

Be a good citizen even without an enforced limit

Nothing stops a tight polling loop today, but nothing has to reward it either. Respect the 6-hour cache window, page through large pulls with offset instead of raising limit past what you need, and if you're running something that calls either endpoint thousands of times a day, say so in an issue - that's exactly the kind of usage that would justify adding real rate limiting.

Ready to use what you just read?

Open the map Check the calendar Browse competitions