How We Secured Our API with Rate Limiting and Key Rotation

API keys inevitably end up somewhere they shouldn't — a public GitHub repo, a client-side bundle, a support ticket screenshot. Assuming leaks will happen and designing for graceful containment is more effective than trying to prevent every possible leak.

Scoped, Least-Privilege Keys

Every API key is scoped to specific permissions (read-only, write, admin) rather than granting full account access by default. A leaked read-only analytics key is a much smaller incident than a leaked key with full account control.

Per-Key Rate Limiting

Rate limits are applied per API key, not just per account, so a single compromised or misbehaving integration can't exhaust the quota for a customer's other legitimate integrations. Limits scale with plan tier and can be increased for verified high-volume use cases.

One-Click Rotation

Customers can rotate any API key instantly from their dashboard, immediately invalidating the old key while issuing a new one. We also support a brief overlap window where both keys work, so customers can update their systems without downtime during rotation.

Anomaly Detection

Sudden spikes in request volume, requests from unusual geographic regions, or a burst of failed authentication attempts trigger an automated alert to the account owner and, for severe cases, a temporary key suspension pending confirmation.

Audit Logging

Every API request is logged with the key used, endpoint accessed, and response code, retained for 90 days and downloadable by the customer. This turns "was our data accessed inappropriately?" from a guessing game into a five-minute log review.

Secrets Storage and Encryption

API keys and integration credentials are never stored in plaintext — we use application-layer encryption on top of database-level encryption, meaning a database dump alone wouldn't expose usable credentials even without access to our encryption keys, which are held in a separate key management service. This defense-in-depth approach means a single compromised layer isn't sufficient to expose sensitive customer data.

Responding to Suspected Compromise

When our anomaly detection flags a potential compromise, our documented incident response process kicks in: the affected key is automatically suspended, the account owner is notified immediately with details of the suspicious activity, and our security team reviews the access logs to determine scope before re-enabling access. Having this process defined and drilled in advance, rather than improvised during an actual incident, meaningfully reduces response time when it matters.

Security isn't a single control — it's a layered system where each individual safeguard reduces the blast radius of the others failing.