Rate Limits

Naburis enforces rate limits at multiple layers to protect platform stability and ensure fair usage across all customers.

Edge Rate Limiting

IP-based rate limits are applied before any application logic runs. These protect against brute-force attacks and volumetric abuse, and apply regardless of authentication status.

Different endpoint categories have different thresholds:

Category	Description
General	All endpoints — standard request rate per IP
API	/api/* endpoints — tighter per-IP limit
Authentication	/oauth/*, /oidc/*, /login* — strictest per-IP limit

Per-Customer Rate Limiting

After authentication, per-customer rate limits are enforced based on your plan tier:

• Higher-tier plans receive higher rate limits
• When your limit is reached, the API returns 429 Too Many Requests with a Retry-After header
• Limits reset on a rolling window basis

Monthly Quotas

Each plan tier includes a monthly request allowance:

• Tracked per customer and reset at the start of each billing cycle
• When the quota is reached, requests return 429 until the next cycle
• Enterprise plans have no monthly cap

Response Headers

Rate-limited responses include standard headers to help your application handle limits gracefully:

HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: <your-plan-limit>
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1709750400

Best Practices

• Respect Retry-After — Wait the indicated number of seconds before retrying
• Implement exponential backoff — For repeated 429 responses, increase wait time between retries
• Monitor X-RateLimit-Remaining — Adjust request rate proactively before hitting limits
• Cache responses — Reduce unnecessary API calls by caching data where appropriate
• Contact support — If you consistently need higher limits, consider upgrading your plan or contacting us