INFORate limiting is available in Cellar API v3.4.0+
Cellar includes built-in rate limiting to protect your deployment from abuse, resource exhaustion, and denial-of-service attacks. Rate limiting is enabled by default and uses a Redis-backed sliding window algorithm.
Rate limiting restricts the number of API requests a client can make within a time window. When a client exceeds their limit, Cellar returns HTTP 429 (Too Many Requests) with information about when they can retry.
Key Features:
Cellar applies different limits based on operation cost:
Endpoints:
POST /api/v1/secret - Create secret (v1)POST /api/v2/secret - Create secret (v2)POST /api/v1/secret/:id/access - Access secret content (v1)POST /api/v2/secret/:id/access - Access secret content (v2)Rationale: These operations involve cryptography (encryption/decryption). The default limit of 300 requests/minute (5 requests/second) aligns with professional-tier REST API standards while remaining conservative relative to underlying cryptography backend capacity. This limit prevents abuse while allowing normal team usage patterns and burst activity.
Endpoints:
GET /api/v1/secret/:id - Get secret metadata (v1)GET /api/v2/secret/:id - Get secret metadata (v2)DELETE /api/v1/secret/:id - Delete secret (v1)DELETE /api/v2/secret/:id - Delete secret (v2)Rationale: These operations query or modify the datastore but don’t involve cryptography. They are less expensive than Tier 1 but still require backend access. The 2x multiplier relative to Tier 1 allows common UI workflows like get metadata → decrypt → delete without hitting rate limits.
Endpoints:
GET /api/v2/config - Query configuration limitsRationale: This endpoint returns cached configuration values with no backend operations. Higher limit allows API clients to frequently query limits before submission without concern for rate limiting.
Endpoints:
GET /health-check - Health check endpointRationale: Monitoring systems need frequent health checks. Very high limit prevents false negatives in monitoring without creating abuse risk, as health checks perform minimal work.
Cellar includes standard rate limit headers on all responses:
On All Responses (200, 201, 400, 404, etc.):
X-RateLimit-Limit: 300 - Maximum requests allowed in window for this endpoint tierX-RateLimit-Remaining: 287 - Requests remaining in current windowX-RateLimit-Reset: 1736705220 - Unix timestamp when window resetsOn 429 Too Many Requests:
X-RateLimit-Remaining: 0)Retry-After: 42 - Seconds until rate limit resetsExample:
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1736705220
Retry-After: 42
{
"error": "rate limit exceeded"
}
Rate limiting is configured through environment variables. See the Configuration Reference - Current Version for complete rate limiting settings and defaults.
X-Forwarded-For header for clients behind proxies/load balancersThe default limits align with professional-tier REST API standards and are suitable for most deployments, including medium-sized organizations. Consider adjusting if:
Increase limits when:
Decrease limits when:
Rate limit violations are logged at INFO level:
Rate limit exceeded for client 192.168.1.100 on tier tier1
Monitor these patterns:
“Rate limit exceeded” for legitimate users:
Rate limiting not working:
RATE_LIMIT_ENABLED=trueFalse positives from monitoring:
RATE_LIMIT_HEALTH_CHECK_REQUESTS_PER_WINDOW