Skip to main content
Learn how rate limiting works at Tesouro and how to interpret rate limit details returned in the GraphQL extensions field.

​
Rate limiting

Rate limiting is a strategy used to control the frequency of requests made to an API. This prevents overuse or abuse, ensuring fair access and stability for all users. By setting limits on the number of requests within a specific time frame, rate limiting safeguards against performance degradation and potential service outages. At Tesouro, we employ rate limiting mechanisms to protect our systems and maintain a consistent experience. The default limit is 50 requests per second. This helps to ensure that no single user or application overwhelms the platform, impacting the performance for others. We monitor and manage request volumes to guarantee that our services remain available and responsive for everyone. This means if a user attempts to send too many requests within a given timeframe, they may encounter a rate limit response and need to adjust their request pattern.

​
Rate limiting responses in extensions

Rate limiting details are included in the extensions field of a GraphQL response. This information will include:
FieldDescription
rateLimit.requestRateThe current rate of requests
rateLimit.remainingThe remaining amount of requests before reset
rateLimit.retryAfterMsHow long one should wait before retrying a request
rateLimit.resetAfterMsHow long until the request rate limit will reset

​
Example rate limit extension response

{
  "data": {
    /* query result here */
  },
  "extensions": {
    "rateLimit": {
      "requestRate": 1,
      "remaining": 48,
      "retryAfterMs": 0,
      "resetAfterMs": 20
    }
  }
}

​
Handling rate limit responses

  1. Understand the rate limit exceeded error: If, for some reason, you find a way to exceed the Tesouro rate limit, you may end up with a request rejected due to rate limiting. This will result in an HTTP 429 status code.
  2. Check the extensions field: Examine the extensions field for rate limiting information. If you find that remaining is zero, you will have exceeded the rate and will need to back off.
  3. Implement backoff strategy: If rate limits are exceeded, implement a backoff strategy. This involves waiting for the resetAfterMs time before retrying the request. Consider using exponential backoff for retries.