# Rate limits

| Limit | Value |
|---|---|
| Requests per key | 300 per minute |
| Requests per creator, all keys together | 5,000 per hour |
| Photo uploads per key | 60 per minute; a batch counts each file |
| Link checks per guide | 12 [check_links](https://developers.sceniq.earth/reference/check_links.md) calls per hour |
| JSON body or MCP message | 2 MB |
| Photo | 6 MB and 6,000 px per side |
| Batch upload | 10 files and 19 MB per request |
| Spots per [upsert_spots](https://developers.sceniq.earth/reference/upsert_spots.md) call | 25 |

Lists inside a row have their own caps (12 links, 30 fees, 20 restrictions per spot and so on); the [field reference](https://developers.sceniq.earth/fields.md) states each one.

## When you hit a limit

A request over a limit answers `429 rate_limited` with a `Retry-After` header (seconds) and `retryAfterMs` in the error body. Wait that long, then continue.

Over MCP, the request limits refuse the HTTP request itself: status 429, the same `Retry-After` header, and a JSON-RPC error `-32000` whose `data.code` is `rate_limited`. The per-guide link check limit comes back as a tool error instead (`Error rate_limited: ...`); wait a few minutes before calling [check_links](https://developers.sceniq.earth/reference/check_links.md) again.

- Never retry in a tight loop; the wait only grows.
- Batch writes: [upsert_spots](https://developers.sceniq.earth/reference/upsert_spots.md) takes 25 spots, [upload_media_batch](https://developers.sceniq.earth/reference/upload_media_batch.md) takes 10 photos.
- Read once, then write: a guide's spots, chapters and places each come back from one list call.
- Resize photos to 2,048 px and compress them before uploading; the server does the rest.
