Rate Limits
Nashra API rate limits — 60 requests a minute per API key, the limits on public signup, contact, and Hub endpoints (per visitor IP and per email address), the rate-limit headers, what a 429 looks like, and how to stay under the limits.
Authenticated endpoints
Authenticated endpoints share one limit per API key: 60 requests per minute, across every authenticated route. An AI assistant connected over MCP gets the same 60 a minute. That's separate from AI assists: each change an assistant makes also uses one of your workspace's monthly AI assists, while reading is free — see AI assists.
Every response carries headers describing where you stand:
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 53
| Header | What it means |
|---|---|
X-RateLimit-Limit | Maximum requests allowed per minute |
X-RateLimit-Remaining | Requests left in the current minute |
Retry-After | Only on a 429 — seconds to wait before retrying |
X-RateLimit-Reset | Only on a 429 — Unix timestamp when you can retry |
Public endpoints
The public endpoints behind your site are limited per visitor instead of per key. Endpoints that take a signup also limit each email address, so one address can't be submitted over and over — however many IPs it comes from.
| Endpoint | Per visitor IP | Per email address |
|---|---|---|
POST /api/subscribe/{identifier} (form action URL) | 10 / minute | 10 / 10 minutes |
POST /api/v1/tenants/{slug}/subscribe | 10 / minute | 10 / 10 minutes |
POST /api/v1/tenants/{slug}/magic-links/{identifier} (Resources) | 10 / minute | 10 / 10 minutes |
POST /api/v1/tenants/{slug}/contact | 5 / minute | 10 / 10 minutes |
GET /api/v1/tenants/{slug}/bio and /resolve/{path} | 60 / minute | — |
GET /api/v1/tenants/{slug}/search-index and /presence | 60 / minute each | — |
Each group has its own allowance, so a reader browsing your Hub doesn't use up the budget they need to subscribe. The three signup endpoints share one per-IP allowance.
For an ordinary site form, that's plenty. If a launch or a busy shared network (an office, a school, a mobile carrier) has real signups hitting the limit, contact support with the form and the time it happened.
Rate limits aren't the only defense on public forms. Every signup endpoint checks a hidden spam-trap field named website, and blatant spam gets a normal-looking success without being saved. Visitors never see a CAPTCHA. See HTML Forms & Form Actions.
Exceeding the limit
Going over returns 429 Too Many Requests:
{
"message": "Too Many Attempts."
}
The Retry-After header tells you how many seconds to wait before trying again.
Best practices
- Cache — Store data locally instead of re-fetching the same information every time.
- Paginate — Use
per_pageandpageto fetch lists in chunks. Default is 15, max is 100. - Batch where possible — Use
POST /subscribers/bulkto upsert up to 100 subscribers per request instead of making 100 individual calls. - Back off on 429 — Wait
Retry-Afterseconds. Use exponential backoff for repeated failures. - Poll on a schedule, not a loop — Nashra doesn't send outgoing webhooks today, so event-driven flows need polling. Poll on a fixed interval — for posts, pass
sincewith your last-seen timestamp rather than re-reading the full list.
If you need to react to a signup the moment it happens, have your own form handle the submission first, then forward it to your Nashra form action URL. See HTML Forms & Form Actions.
Need higher limits?
If your integration legitimately needs more than 60 requests a minute, write to support@nashra.ai. Include the key's name and your expected request volume.