Nuntly’s API enforces rate limits to ensure equitable resource distribution among users and to maintain system stability.

Understanding Rate Limits

Rate limits define the maximum number of API requests a user can consume within a specific timeframe, such as per minute. Developers must design applications to handle these limits gracefully, using techniques like request batching, caching, and exponential backoff. If you are using our official SDKs, it will handle these details for you.

Why Do We Have Rate Limits?

Rate limits are a standard practice in API design, ensuring stability, security, and fair usage. Here’s why they matter:
  • Prevent Abuse & Misuse: Rate limits act as a safeguard against excessive or malicious API usage, protecting both the platform and its users.
  • Ensure Fair Access: By capping requests, we prevent a small number of users from monopolizing resources, ensuring consistent performance for everyone.
  • Maintain System Stability: Rate limits help Nuntly manage traffic spikes and overall infrastructure load, keeping response times predictable.
  • Enhance Performance & Reliability: Controlled request flow improves API uptime and minimizes throttling, ensuring a smooth experience for developers.

Rate limits in headers

The API server automatically sets headers to inform you about their rate limit status. These headers include:
  • ratelimit-limit: The maximum number of requests allowed within the defined time window.
  • ratelimit-policy: Provides details on the rate-limiting rules, such as the request limit, the time window, and the enforcement strategy
  • ratelimit-remaining: The number of requests the client can still make within the current time window before hitting the limit.
  • ratelimit-reset: The time in seconds when the rate limit will reset.

Rate limits status code

HTTP status code 429 indicates Too Many Requests, it means that you hit the rate limit. When you receive a 429 status, you should respect the rate limit by waiting before sending more requests. The API server may also include a ratelimit-reset header to specify how long you should wait before making another request.