Rate Limiting & Quotas

The gateway enforces limits in both directions: how often consumers can call us, and how often we can call our own resources.

Inbound: Per-Consumer Limits

Every consumer has:

• requests_per_minute
• requests_per_hour
• concurrent_in_flight

Enforced at the auth middleware. Limits are per API key. Exceeding returns 429 with a Retry-After header.

Outbound: Per-Resource Limits

The gateway tracks each of our resources' limits and refuses to exceed them. These limits belong to us; protecting them is protecting our relationship with our vendors.

Salesforce Governor Limits

• 100 API calls per user per rolling 24h window
• 15,000 API calls per org per rolling 24h window
• Concurrent long-running operations: 25
• Composite request: up to 25 subrequests

Strategy

• Per-user connection pool — each gateway worker that talks to SF uses a dedicated integration user, so the 100/user budget is isolated
• Org-wide budget tracker — Redis counter incremented on every call
• Bulk endpoints preferred — Composite requests count as one call but do up to 25 subrequests
• Pre-flight check — before calling SF, check budget; if <10% remains, fail fast with sf_quota_low

General Pattern

Each connector declares:

• calls_per_window
• window_seconds
• burst_capacity

The gateway enforces these before dispatching.

Backpressure

If a resource is at quota:

1. Return 429 Too Many Requests with a Retry-After header
2. Log the event
3. Increment a quota_exceeded metric

Consumers are expected to honor Retry-After.

Spike Status

Not implemented in the spike. The spike has no rate limiting, no quota tracking, no backpressure. All three are production requirements.