--- title: "Document360 API Rate Limits" slug: "rate-limiting" description: "Complete guide to Document360 API rate limits: understand tier-based limits, handle 429 errors, implement retry logic, and optimize your API integration for reliable performance." tags: ["Rate Limits", "API Management", "Subscription Tiers"] updated: 2026-10-26T09:30:18Z published: 2026-10-26T09:30:18Z canonical: "apidocs.document360.com/rate-limiting" --- > ## Documentation Index > Fetch the complete documentation index at: https://apidocs.document360.com/llms.txt > Use this file to discover all available pages before exploring further. # Understanding rate limiting Document360's API allows you to programmatically access and manage your knowledge base content, including articles, categories, and user data. To ensure reliable service and fair usage for all customers, we implement rate limits that control how many API requests you can make within a specific time period. Rate limits prevent any single user from overwhelming our servers and help maintain consistent performance across our platform. ## Tier limits Rate limits are applied per `api_token` - the unique authentication key that identifies your Document360 account when making API calls. Each subscription tier has different rate limit allowances based on your plan's features and capacity. Read requests and write requests have separate limits: - **Read requests** fetch content (GET). - **Write requests** create, update, or delete content. Because the two are counted separately, heavy write activity such as a bulk import doesn’t use up your read limit, and heavy reading doesn’t use up your write limit. API access is available on the Business, Enterprise, and Trial plans. The standard limits for each plan are: | Plan | Read (requests per minute) | Write (requests per minute) | | --- | --- | --- | | Business | 120 | 60 | | Enterprise | 200 | 100 | | Trial | 200 | 100 | > [!NOTE] > NOTE > > - These are our standard rate limits. Your project may have different limits based on your commercial arrangement. To see the limit that applies to a request, check the `X-RateLimit-Limit` header in the response. > - If you've exhausted your limits, you can restructure your integrations or upgrade to a higher tier. If your integrations regularly exceed the limit, consider optimizing request frequency using caching or batching strategies. --- ### Rate limit responses Every API response tells you your limit and how many requests you have left: - `X-RateLimit-Limit`: your limit for this type of request. - `[X-RateLimit-Remaining]`: how many requests you have left in the current window. If you go over your limit, the API returns `[429 Too Many Requests]` along with `[Retry-After]`, which gives the number of seconds to wait. Wait that long before you retry. If you retry sooner, the request is rejected again. If your integrations regularly go over the limit, you can send requests less often by caching responses or batching requests, or you can upgrade to a higher plan. --- ## Header information Every API response includes headers that help you monitor your usage: - **X-RateLimit-Limit:** The maximum number of requests that can be made by the current `api_token` - **X-RateLimit-Remaining:** The remaining number of calls within the time window - **X-RateLimit-Reset:** The number of seconds before the limit is reset Once you exhaust the request limit, any concurrent API call will return an error response with an **HTTP code 429**. You can refer back to the **X-RateLimit-Remaining** header, which will inform you when the limit will reset. > [!NOTE] > NOTE > > By default, only the `X-RateLimit-Remaining` header is included in each response. Once the limit is reached, `X-RateLimit-Limit` and `X-RateLimit-Reset` headers are also included. --- ### FAQ #### What counts as a request? Each API call you make (GET, POST, PUT, DELETE) counts as one request toward your limit. This includes retrieving articles, creating content, updating categories, or any other API operation. #### What are the best practices for managing rate limits? 1. Monitor your usage Always check the `X-RateLimit-Remaining` header in your responses to track how many requests you have left. 2. Implement rate limit handling Build error handling into your code to manage 429 responses gracefully. 3. Optimize your requests - **Use caching**: Store frequently accessed data locally to reduce API calls - **Batch operations**: Combine multiple updates into a single request when possible - **Paginate efficiently**: Use appropriate page sizes when retrieving large datasets - **Schedule non-urgent tasks**: Spread out bulk operations over time 1. Choose the right approach - For real-time applications: Monitor headers closely and implement retry logic - For bulk operations: Use smaller batches with delays between requests - For periodic syncing: Schedule operations during off-peak hours #### What to do when you regularly exceed limits? **Immediate solutions:** 1. Restructure your integrations: Optimize your code to make fewer API calls 2. Implement caching: Store data locally to reduce repeated requests 3. Add delays: Space out your API calls to stay within limits **Long-term solutions:** 1. Upgrade your tier: Higher-tier plans offer increased rate limits 2. Contact support: If you have legitimate high-volume needs, our team can discuss custom solutions ## Related - [Introduction](/endpoints-introduction.md) - [Gets all workflow statuses for a project](/gets-all-workflow-statuses-for-a-project.md) - [Adds files to Drive](/add-file-in-to-drive.md)