Our integration team will hammer your API from batch jobs. How do you protect the platform — and how do you protect us from surprise throttling?

The full executive answer

Both directions are engineered, and transparently. Protecting the platform: every API key carries two limits — requests per minute for burst control and requests per day for volume control. Defaults come from your subscription tier, stored in the database rather than hard-coded, and per-key overrides exist precisely for negotiated batch workloads like yours — so 'we need 50,000 calls nightly' is a contract line, not a support fight. Every request is logged and rate-limit state is cleaned up by a scheduled job; abuse of one key cannot degrade another tenant, which is the multi-tenant fairness obligation.

Protecting you from surprises: limits are explicit and inspectable rather than adaptive black-box throttling, and the right client behaviour is supported end-to-end — idempotency keys mean a retried batch write cannot double-apply, and our own SDKs are built for retry-with-backoff semantics. In Google SRE terms this is standard load-shedding at the boundary: the platform degrades predictably under overload instead of unpredictably for everyone.

Practical commitment for your team: in a pilot we set the key limits with you against your real batch profile, and you can watch your own consumption via request logs. Honest note — self-service usage dashboards per key are roadmap; today that visibility is provided, not self-serve.