Skip to main content

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:
Creating events is resource-intensive and has a lower limit (10/minute) compared to read operations (60/minute). Plan your integration accordingly, especially for bulk operations.

Rate Limit Headers

Every API response includes rate limit information in the following HTTP headers:

Reading Rate Limit Headers

Monitor the X-RateLimit-Remaining header to track your usage and avoid hitting rate limits. Implement throttling when this number gets low.

429 Rate Limit Exceeded

When you exceed the rate limit, the API returns a 429 Too Many Requests response with additional information:

Response Format

HTTP Status: 429 Too Many Requests Headers:
Body:

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:
❌ 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