A Play Integrity verdict tells your backend whether a request came from your unmodified app, installed by Google Play, on a genuine certified Android device. It is evidence for your anti-abuse logic, not proof of who the user is, and Google says it should not be your only defence.
What the verdicts cover
Google's overview describes three core verdicts that every integration can read:
| Verdict | Question it answers |
|---|---|
| accountDetails | Did the user install or pay for the app on Google Play? |
| appIntegrity | Is this your unmodified binary that Google Play recognises? |
| deviceIntegrity | Is the app running on a genuine certified Android device? |
Developers can also opt in to additional signals. Google lists a stronger device integrity level that indicates recent security updates on Android 13 and higher, a verdict about other apps that could capture the screen or control the device, a Play Protect verdict, a recent device activity level that can hint at automated traffic, and a beta device recall feature for repeat abuse.
The word "genuine" matters. These checks say something about the environment around the request. They say nothing about whether the person holding the phone is allowed to see a given record.
Standard or classic requests
There are two ways to ask for a verdict, and the response format is the same.
| Standard | Classic | |
|---|---|---|
| Typical latency | A few hundred milliseconds | A few seconds |
| Warm up needed | Yes, a few seconds | No |
| Good for | Frequent checks on any action | One off checks on the most sensitive actions |
| Replay protection | Handled by Google Play | You must use the nonce field with server side logic |
Google advises against making a classic request and caching it for later. If you want to reuse a result, use standard requests instead, which lowers the risk of replay style attacks.
A rollout plan that avoids locking out real users
Google recommends gathering telemetry before you act. A sensible order:
- Call the API from the app and send the token to your backend, but do not enforce anything yet.
- Record the verdicts you see across your real install base, split by app version and device type.
- Estimate who a rule would block. If a large share of ordinary users would fail, the rule is wrong or the integration needs work.
- Pick actions to protect first, such as account creation, payments or bulk export.
- Choose a response per failure: allow and log, add a step up check, rate limit harder, or block.
- Revisit after each release, since verdicts change as devices and the API change.
Always verify the token on your server. Decoding and judging the verdict inside the app defeats the point, for the same reason Apple gives for its own attestation service: a tampered app can lie about its own results.
Limits to plan around
By default Google allows up to 10,000 total requests per day across all installs, and you can ask for a higher limit. If you call the API on every request from a large app, you will hit that quickly. Call it for sensitive actions, not for every list refresh.
Google also says the API works well next to other signals as part of an overall anti-abuse strategy. In practice that means rate limits, account level checks and server side authorization keep doing their jobs.
Where it fits for partner and mobile APIs
Use the verdict to decide how much to trust a request from your own app. It does not help with partner server to server traffic, since those clients are not Android apps. For partners, rely on scoped credentials, sender constrained tokens and logs.
Safeguard does not offer app attestation. Its SBOM and dependency scanning can show which libraries ship in your Android build, and a free scan is available at gold.safeguard.sh/scan.
Quick check
Can I trust the verdict if I check it inside the app?
No. Send the token to your server and verify it there, because app side checks can be falsified.
Is a passing verdict enough to skip authorization checks?
No. It speaks about the app and device. You still need authentication and per object authorization on the server.
Should I block every failed verdict on day one?
Google recommends measuring first. Collect verdicts without enforcement, estimate the impact, then choose a response per action.
Sources
Last reviewed: 19 October 2026.
