Skip to main content
To ensure high availability, stability, and zero-latency performance for all customers, the Connexease Edge Gateway enforces rate limits on incoming API requests. These limits also protect your application from being penalized by Meta’s upstream rate limits. Rate limits are applied per App ID (which is tied to your API Key).

Default Limits

By default, the gateway enforces the following high-throughput limits:
  • 100 requests per second
  • 1,000 requests per minute
If you have a high-volume enterprise plan, your specific rate limits may be higher. The HTTP headers returned with every request will always reflect your current limits.

Rate Limit Headers

Every API response includes standard HTTP headers that provide real-time information about your current rate limit status. You can use these headers to pace your requests dynamically in your code.
HeaderDescription
X-RateLimit-sec-LimitThe maximum number of requests you are allowed to make per second.
X-RateLimit-sec-RemainingThe number of requests remaining in the current one-second window.
X-RateLimit-min-LimitThe maximum number of requests you are allowed to make per minute.
X-RateLimit-min-RemainingThe number of requests remaining in the current one-minute window.

Handling Rate Limit Errors

If you exceed the allowed number of requests, the API will reject subsequent requests and return an HTTP 429 Too Many Requests status code. The response body will use our unified error format, clearly indicating how long you need to wait before making another request via the retry_after parameter.
{
  "isSuccess": false,
  "errors": {
    "code": "RATE_001",
    "group": "TOO_MANY_REQUESTS",
    "description": "Rate limit exceeded. Please try again later.",
    "params": {
      "limit_type": "sec",
      "retry_after": "1 seconds"
    }
  }
}

Best Practices for High Volume Sending

  • Implement Backoff: If your code receives a 429 error, parse the retry_after parameter from the errors.params object, and pause your application’s request loop for that duration before retrying.
  • Queue Your Traffic: For massive outbound messaging campaigns, do not use a simple for loop. Use an internal queue (like RabbitMQ or Redis) to throttle your own traffic so it stays slightly below the maximum allowed limits (e.g., emit at 90 req/sec).