Rate limiting

When using the Call connector endpoint if you exceed the rate limiting policy of the 3rd party service you are calling, the 429 response will be contained within a Tray 200 response:

{
  "response": {
    "statusCode": 429,
    "body": {
      "ok": false,
      "error": "ratelimited"
    }
  },
  "expects": {
    "statusCode": [200]
  },
  "message": "Too many requests have been made in the given timeframe."
}

Possible causes:

• Attempting repeated requests, or processing large volumes of data without throttling requests - e.g. adding a 1 minute delay between calls
• If implementing pagination you may need to set up an exponential backoff to ensure that you do not e.g. pull 1000 pages with only a second in between each request
• Using non-optimal connector operations e.g. dedicated 'batch update' operations which are designed to reduce the amount of requests you need to make
• A sudden increase in your End User activity without any of the above measures in place

If you are exceeding the rate limits of a 3rd Party you will either need to implement one of the above solutions, or you will need to arrange for your rate limits to be increased with the 3rd party.

The following screenshot shows an example from the [Google Cloud console(https://console.cloud.google.com/)] which displays data on your limits and usage:

Handling limiting gracefully

A basic technique for integrations to gracefully handle limiting is to watch for 429 status codes within the response body and build in a retry mechanism.

The retry mechanism should follow an exponential backoff schedule to reduce request volume when necessary. We’d also recommend building some randomness into the backoff schedule to avoid a thundering herd effect.