Overview
The BookingShake API implements rate limiting to ensure fair usage and maintain service quality for all users. Rate limits are applied per API key and per endpoint, with different limits based on the operation complexity.Rate limits are tracked using fixed 1-minute windows (aligned on clock minutes). The
X-RateLimit-Reset header tells you when the current window ends.Rate Limit Table
Different endpoints have different rate limits based on their resource intensity:Rate Limit Headers
Every API response includes rate limit information in the following HTTP headers:Reading Rate Limit Headers
429 Rate Limit Exceeded
When you exceed the rate limit, the API returns a429 Too Many Requests response with additional information:
Response Format
HTTP Status:429 Too Many Requests
Headers:
Response Fields
The
Retry-After header tells you exactly how many seconds to wait before making another request. Always respect this value to avoid continued throttling.Handling Rate Limits
1. Detect and Wait
The simplest approach is to detect 429 errors and wait for the specified time:2. Exponential Backoff with Jitter
For production applications, implement exponential backoff with jitter to handle rate limits gracefully:3. Request Queue with Rate Limiter
For applications making many requests, implement a queue with built-in rate limiting:Best Practices
Monitor Headers
Always check
X-RateLimit-Remaining to proactively avoid hitting limits. Implement throttling when the count gets low.Respect Retry-After
When you receive a 429 response, always wait for the duration specified in the
Retry-After header before retrying.Implement Backoff
Use exponential backoff with jitter for automatic retry logic to handle temporary rate limit issues gracefully.
Use Queues for Bulk
For bulk operations, implement a request queue with built-in rate limiting to stay within limits automatically.
Cache Responses
Cache responses from GET endpoints (sources, spaces, status, fields) to reduce unnecessary API calls.
Batch When Possible
Use the batch booking feature of
/events/create to create multiple events in a single request rather than multiple separate requests.Optimizing for Rate Limits
1. Cache Static Resources
Resources like sources, spaces, and statuses rarely change. Cache them locally:2. Batch Event Creation
Instead of creating events one by one, batch them:Single Request vs Batch
Single Request vs Batch
❌ Inefficient - 10 separate requests:✅ Efficient - 1 request:
3. Implement Request Deduplication
Avoid making the same request multiple times:Need Help?
Error Handling
Learn about all error codes and how to handle them
Contact Support
Get help optimizing your integration
