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 api_token has two separate limits, one for read requests and one for write requests, and each subscription tier has different allowances based on your plan's features and capacity.
Read requests use the
GETandHEADmethods, for example retrieving articles, listing categories, or pulling analytics.Write requests use the
POST,PUT,PATCH, andDELETEmethods, for example creating, updating, publishing, or deleting content.
Because the two limits are independent, heavy read activity, such as a bulk export, pulling analytics or usage reports does not reduce your ability to write, and vice versa.
Rate limits by subscription tier
Plan tier | Read (requests per minute) | Write (requests per minute) |
|---|---|---|
Business | 120 | 60 |
Enterprise | 200 | 100 |
Enterprise Plus | 200 | 100 |
Trial | 200 | 100 |
NOTE
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.
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_tokenX-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
By default, only the
X-RateLimit-Remainingheader is included in each response. Once the limit is reached,X-RateLimit-LimitandX-RateLimit-Resetheaders are also included.
FAQs
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?
Monitor your usage
Always check the
X-RateLimit-Remainingheader in your responses to track how many requests you have left.Implement rate limit handling
Build error handling into your code to manage 429 responses gracefully.
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
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:
Restructure your integrations: Optimize your code to make fewer API calls
Implement caching: Store data locally to reduce repeated requests
Add delays: Space out your API calls to stay within limits
Long-term solutions:
Upgrade your tier: Higher-tier plans offer increased rate limits
Contact support: If you have legitimate high-volume needs, our team can discuss custom solutions