Firebase App Check Pricing and Quotas: Separate Attestation from Backend Usage

Identify the provider and protected product

The App Check overview links provider quotas and supported services. Android Play Integrity has its own setup and request limits described in the Play Integrity documentation.

Use the project's current console and provider documentation for exact quotas and eligibility. Do not copy a quota from another project, billing plan or attestation provider as a universal allowance.

Model requests separately

One App Check token can be used according to the SDK's lifecycle; do not assume every database read necessarily produces a fresh attestation call.

Review token lifetime trade-offs

The Android provider guide explains supported configuration. Shorter token lifetimes may change request volume, latency and abuse exposure. Choose values based on the documented limits and actual threat model rather than maximizing refresh frequency automatically.

Test failure behavior under limits

Determine what the app and backend do when token acquisition fails or a provider is temporarily unavailable. An uncontrolled retry loop can worsen quota pressure and degrade the user experience.

Use bounded retries and observable error handling appropriate to the SDK. Do not replace verification with unconditional acceptance simply because a quota was reached.

Keep the estimate dated

Record provider, project, billing plan, quota approval and measurement window. APKLint's Firebase Config Scanner cannot read billing or provider quotas and should not be used to estimate them. Use observed traffic and the current official provider/product tables to build the budget, then revisit it after rollout or a substantial change in active usage.