sethvargo
commented
3 years ago Hi @greggles,
1. More 500 responses than I expect...
Are you getting a response body? It should include an errors key. If not, can you let me know which server you're using and I can investigate and see if there's anything in the server logs. Timestamps would be helpful too.
2. Getting 429 responses...
The possibility of a rate limited is documented in api.md, but you're correct that we do not document the specific rate limits.
Rate limiting can occur at the following levels, in order:
-
API keys - If an API key is provided, the system rate limits by the realm associated with the API key, by client IP address. API keys are specified as the X-API-Key HTTP header, but not all endpoints require that header.
-
User ID - If a user is authenticated to the system (only applies to the UI server), they are rate limited by user ID. Since a user can be a member of multiple realms, the enforcement mechanism here is per-user, not per-realm.
-
IP address - If no authentication information is present, rate limiting is applied by the requestor's IP address.
When a request is rate limited, it will return a 429 Too Many Requests. The response headers will include an X-Retry-After header, which indicates when it is safe to retry the request.
The current global rate limit is 60 tokens per minute (note this is NOT the same as 1 token per second, although that is one possible use), however we reserve the right to change this rate limit as-needed.
It's unlikely we'll every drop below 60 tokens/minute, so I would build around that metric, and then bundle any requests that were rate limited into a retry.
greggles
mikehelmick
google-oss-robot
Question
We are testing out sending out codes to phone numbers in batches (happy to discuss the motivation and use case separately from this issue).
I've built out error handling for the various response messages to expect in the API.md but find
More 500 responses than I expect - I'm starting to guess these are numbers on a block list from Twilio? Is there any way to know how/why these are happening?
Getting 429 responses. These are not documented, so I'm really curious about them. Currently the script calls the API in a pretty tight loop, issuing ~100 codes within a few seconds. Should we implement a sleep in the loop to avoid some request threshold? This does not have to be a high throughput process.