Optimizing usage
To avoid exceeding your plan limits, we recommend optimizing your API requests to ensure you aren't being billed for redundant, error-prone, or bad requests.
Bad requests
While 50X server error codes are excluded from the requests count, we include 4XX error codes since these indicate issues with the request itself.
Empty params
A common issue for 400, 422 and 404 errors is a blank or missing param.
Bad token
401 and 403 are also taken into account as part of your limit quota, so ensure requests include valid, non-expired authentication tokens.
Tokens are type-specific as well — for example, Admin V2 tokens won't work on Headless Auth API. A wrong token type will also result in a 403.
Method not allowed
Double check your HTTP methods (GET, POST, PUT, DELETE, PATCH) to ensure you're sending through the ones allowed on each endpoint. Methods that are not allowed will result in a 405.
Rate limit
Sending a lot of requests in a small timeframe can lead to a 429 (Too Many Requests). Our rate limit policy is generous, but when you encounter a response code 429, we recommend waiting for around 60 seconds to send through more requests.
It might helpful for you to implement waits and delays in your code to avoid exceeding rate limits.
Optimizing endpoints
The "Endpoints overview" section in your Developer dashboard shows you an overview of your requests broken up by endpoint.
Single x Multiple calls
When an API endpoint allows multiple params for bulk actions, we recommend using these instead of making multiple requests. For example, to add a member to multiple spaces or space groups, you can pass a list of space_ids or space_group_ids in a single call instead of making multiple requests to add members to each space.
Caching
A caching layer on your end can help you make requests only when you need to.
For example, we recommend caching static datasets which don't change that often; i.e. spaces or community members.
Error handling
Since 4XX errors are counted towards your request limit, we recommend using a circuit breaker pattern to prevent cascading failures.
For example, if the first request fails, don't perform the second request since it will likely fail too.
Last updated
