Rate Limits

SinglebaseCloud implements rate limiting to ensure fair usage and optimal performance. Rate limits are applied per API key and user, with different limits for various operation types.

Rate Limit Overview

API	Operation Type	Limit	Window
Datastore	Read operations (collection.find, collection.count)	1,000 requests	Per hour
Datastore	Write operations (collection.insert, collection.update)	500 requests	Per hour
Datastore	Bulk operations (collection.delete, collection.archive)	100 requests	Per hour
Auth	Authentication (auth.signin, auth.signup)	100 requests	Per hour
Auth	Profile operations (auth.update_profile, auth.update_account)	50 requests	Per hour
Auth	OTP operations (auth.send_otp)	20 requests	Per hour
Storage	File operations (file.info, file.update, file.delete)	500 requests	Per hour
Storage	Upload operations (file.presign_upload, file.postsign_upload)	200 requests	Per hour

Rate Limit Headers

All API responses include rate limit information:

X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 847
X-RateLimit-Reset: 1681234567
X-RateLimit-Window: 3600

• X-RateLimit-Limit: Maximum requests allowed in the current window
• X-RateLimit-Remaining: Requests remaining in the current window
• X-RateLimit-Reset: Unix timestamp when the limit resets
• X-RateLimit-Window: Window duration in seconds

Rate Limit Exceeded Response

When limits are exceeded, the API returns HTTP status 429 Too Many Requests:

{
  "error": {
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "Rate limit exceeded. Try again in 1847 seconds.",
    "details": {
      "limit": 1000,
      "remaining": 0,
      "reset_at": 1681234567,
      "retry_after": 1847
    }
  }
}

Best Practices

Request Optimization

• Use batch operations when possible to reduce request count
• Implement client-side caching for frequently accessed data
• Use webhooks instead of polling for real-time updates
• Optimize queries to fetch only necessary data

Error Handling

• Monitor rate limit headers to prevent hitting limits
• Implement exponential backoff for retry logic
• Use the retry_after value from error responses
• Return appropriate HTTP status codes in your application

Traffic Management

• Distribute requests evenly throughout the rate limit window
• Queue non-urgent requests during peak usage
• Implement circuit breaker patterns for resilience
• Monitor usage patterns and adjust request timing

Monitoring Usage

Track your API usage in the SinglebaseCloud Console:

• Real-time request counts and rate limit utilization
• Historical usage patterns and trends
• Alert notifications when approaching limits
• Usage breakdown by API and operation type

Common Issues

High rate limit usage:

• Review query efficiency and implement batching
• Add caching layers for repeated requests
• Use webhooks for real-time data instead of polling

Frequent 429 errors:

• Implement proper retry logic with exponential backoff
• Reduce request frequency during peak periods
• Consider upgrading to a higher tier

Inconsistent behavior:

• Verify single API key usage across applications
• Monitor for burst traffic patterns
• Check rate limit headers in all responses