API Keys
API keys authenticate your app with the Qafka backend. They are public-by-design — safe to ship in your app binary because each request is gated by bundle ID, platform, and device attestation. See API Key Security for the full validation chain.
Key Types
| Type | Prefix | Use Case |
|---|---|---|
| Production | qafka_prod_ | Production traffic — billed and rate-limited per the project’s subscription plan |
| Test | qafka_test_ | Development and testing — separate counters from production, allowed on simulators where attestation can’t run |
Key Lifecycle
A new key is generated on the server and shown to you exactly once — there is no way to recover the plain string later, only rotate the key (which generates a fresh value and invalidates the old one). Treat the moment of creation as the single chance to copy the value into wherever your app reads it from.
Setting platform and bundle ID restrictions at creation time is strongly preferred over leaving them empty and adding them later — an unrestricted key in a published binary is a much bigger blast radius if it leaks than a restricted one.
Restrictions
Platforms
Limit which platforms can use the key:
ios— iOS apps onlyandroid— Android apps only
Leave empty to allow both.
Bundle ID
Lock the key to specific app bundle IDs (one per platform). The bundle ID is verified server-side via device attestation, so it can’t be spoofed by setting a header.
| Field | Example |
|---|---|
| iOS bundle ID | com.yourcompany.yourapp |
| Android bundle ID | com.yourcompany.yourapp |
Rate Limits & Quotas
Rate limits aren’t configured per key — they come from the active subscription plan for the project. Limits apply across three axes (per API key, per IP, per session) and are enforced uniformly. See Error Handling › Throttling for the response headers and 429 shape.
To raise limits beyond your plan’s defaults, upgrade the plan or contact us about per-project overrides.