Overview

Rate limits control how many API requests you can make per hour. They prevent abuse, ensure fair usage, and maintain platform stability for all users.

Rate Limit Tiers

Burst Limit allows short bursts of requests exceeding the average rate. Useful for batch operations.

How Rate Limiting Works

Sliding Window

Bluma uses a sliding window algorithm:
This is more accurate than fixed windows and allows for smoother usage patterns.

Rate Limit Headers

Every API response includes rate limit information:

Reading Headers

Rate Limit Exceeded (429)

When you exceed your rate limit, you’ll receive a 429 Too Many Requests response:
Additional Header:
The Retry-After header indicates how many seconds to wait before retrying.

Handling Rate Limits

1. Exponential Backoff

2. Request Queue

3. Monitoring Usage

Per-Key vs Account-Wide

Rate limits are applied per API key, not per account. This allows you to:
  • Create separate keys for different applications
  • Isolate production from development traffic
  • Scale horizontally with multiple keys

Example: Multiple Keys

Each key has its own independent rate limit.

Upgrading Limits

Increase Your Tier

Higher tiers get higher rate limits:
Upgrade at getbluma.com/billing

Custom Limits

Enterprise customers can request custom rate limits based on their specific needs. Contact sales@getbluma.com.

Best Practices

Check Headers

Monitor rate limit headers and adjust request rate dynamically

Implement Backoff

Use exponential backoff when receiving 429 responses

Cache Responses

Cache frequently accessed data (templates list, etc.) to reduce API calls

Batch Operations

Combine multiple operations when possible to reduce request count

Exceptions

Rate limits do not apply to: ✅ Webhook deliveries (server-initiated) ✅ OAuth token refresh (authentication) ✅ Health check endpoints Rate limits do apply to: ❌ All /v1/* API endpoints ❌ OpenAPI spec endpoint (/v1/openapi.json)

Testing Rate Limits

Simulate Rate Limiting

Test your backoff logic using test keys with artificially low limits:
Then make >10 requests to trigger rate limiting.

Frequently Asked Questions

Yes! Upgrade your tier or contact sales@getbluma.com for custom limits (Enterprise only).
No, rate limits use a sliding window. They reset continuously based on your request pattern.
Every HTTP request to /v1/* endpoints counts, regardless of success or failure.
Yes, test keys have the same rate limits as production keys of your tier. This helps you test rate limit handling logic.
Bluma currently doesn’t support WebSockets. All communication is via HTTP REST API.

Troubleshooting

Issue: Constant 429 Errors

Causes:
  • Making too many requests too quickly
  • Multiple API keys from same account hitting shared limit
  • Batch operations without rate limiting
Solutions:
  • Implement request queueing
  • Add delays between requests
  • Upgrade to a higher tier
  • Use exponential backoff

Issue: Unexpected Rate Limit

Causes:
  • Previous requests in the sliding window
  • Shared API key across multiple services
  • Clock skew in reset time calculation
Solutions:
  • Check X-RateLimit-Remaining header
  • Use separate API keys per service
  • Monitor usage in dashboard

Monitoring

Track rate limit metrics in your usage dashboard:
  • Current usage vs limit
  • Historical rate limit hits
  • Per-key usage breakdown
  • Average requests per hour

Next Steps

View Usage Dashboard

Monitor your API usage in real-time

Upgrade Plan

Increase your rate limits

Error Handling

Learn how to handle 429 errors

Best Practices

Build rate-limit-aware integrations