> For the complete documentation index, see [llms.txt](https://api.circle.so/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://api.circle.so/apis/admin-api/usage-and-limits/optimizing-usage.md). # 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 most 4XX](/apis/admin-api/usage-and-limits.md) 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. A missing required param returns a 404. ```bash // good request GET /api/admin/v2/community_members/123 GET /api/admin/v2/community_members/search?email=jane@example.com // bad request GET /api/admin/v2/community_members/undefined GET /api/admin/v2/community_members/search ``` #### Bad token Ensure requests include a valid authentication token. A missing or invalid token results in a 401. 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 401. A 403 means your community's plan isn't eligible for the API. 403 responses count toward your limit quota. #### 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 404. #### Rate limit Sending a lot of requests in a small timeframe can lead to a 429 (Too Many Requests). Our [rate limit policy](/apis/admin-api/usage-and-limits.md#rate-limits) is generous, but when you encounter a response code 429, we recommend backing off and retrying later. The limit is measured over a 5-minute window. 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, when you create or update a member, you can pass a list of space\_ids or space\_group\_ids in that same call instead of making multiple requests to add the member 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 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.