What is Play Integrity API?

Google’s Play Integrity API lets your backend assess the environment where a Play-distributed Android app runs — device and install integrity signals based on your Play Console setup (app integrity).

What is app integrity in Google Play Console?

It refers to Play Console settings and signals tied to Play Integrity that help distinguish trusted installs and devices from altered or emulator environments, according to the rules you enable for your app.

How much does Play Integrity cost in a tester campaign?

Play Integrity itself is a Google service. On Tester Marketplace, optional Integrity fits into campaign budgets you set (see /en/pricing) — there is no fixed per-tester platform fee.

When should a tester campaign require Integrity?

When fraud risk is high, builds must stay on trusted devices, or you need stronger evidence than telemetry alone. It adds integration cost; skip it for low-risk closed testing quotas.

Who configures Integrity on Tester Marketplace?

Publishers invite the service account in Play Console, integrate Integrity in the tester build, and post tokens to the campaign API. Testers see when a token is required in their progress.

What does MEETS_DEVICE_INTEGRITY mean?

It's the highest device integrity verdict in Play Integrity API: the device meets Android compatibility standards and isn't rooted or tampered with. MEETS_BASIC_INTEGRITY is a more permissive tier (includes certified emulators) and MEETS_STRONG_INTEGRITY adds hardware-backed certification.

Standard API or Classic API for Play Integrity?

Use the Standard API for a new integration: it's faster, uses local caching, and is what Google has recommended since 2023. The Classic API makes one network call per check and is being phased out.

Technical guide

Play Integrity API Android — Beta Campaign Guide

Play Integrity API & Play Console app integrity: when to require it in paid beta testing, pricing guidance, and server-side token checks with Tester Marketplace.

Short definition

Play Integrity API lets your backend assess the environment where your Play-distributed Android app runs — device, install integrity and more, per your Play Console setup. It is Google's attestation layer for apps distributed through Play; verdicts are meant to be checked server-side, not trusted from the client alone.

Why publishers use it in beta campaigns

Paid or quota-driven testing attracts abuse: emulators, rooted devices, or people who install once and never play. Integrity does not replace session/event rules — it adds a trust signal that the install environment looks legitimate before you count the assignment as complete.

High-value soft launches where fraud would waste budget.
Builds that must stay off unofficial sideloads.
Campaigns where telemetry alone is not enough evidence of a real device.

The three Play Integrity verdicts

Decoding a Play Integrity token on your server returns three independent verdict blocks:

Device integrity — whether the device meets Android compatibility standards and isn't rooted or tampered with. MEETS_DEVICE_INTEGRITY is the highest tier; MEETS_BASIC_INTEGRITY is a weaker environment (can include Google-certified emulators); MEETS_STRONG_INTEGRITY adds hardware-backed certification.
App integrity — whether the running APK/AAB matches what you published on Play and hasn't been modified or redistributed outside your official channel.
Account details — LICENSED if the Google account running the app has a Play licensing entitlement (installed from Play or an authorized channel), or UNLICENSED otherwise.

For tester campaigns, requiring at least MEETS_BASIC_INTEGRITY + LICENSED is typical; reserve MEETS_DEVICE_INTEGRITY for high fraud-risk campaigns (large cash rewards, real-money apps).

Standard API vs Classic API

Google offers two ways to request a verdict: the Standard API (recommended since 2023, faster, with local caching) and the Classic API (one network call per check, being phased out). For a new integration in 2026, use the Standard API unless you already have Classic implemented and working.

Common implementation mistakes

Treating a MEETS_BASIC_INTEGRITY verdict as a failure — it isn't; it just signals a lower trust tier (common on Google-certified emulators used by legitimate testers).
Checking the token only on the client. Verdicts must be decoded and their signature validated on your server; trusting a boolean returned by the client itself defeats the protection.
Not validating the requestHash / nonce against the one your backend generated — without that check, a valid token from another session can be replayed.
Hard-blocking testers on rooted devices or outdated Play Store versions with no fallback: for testing campaigns (unlike real-money production), logging the verdict and deciding case-by-case usually beats an automatic rejection.

Inside Tester Marketplace

Publishers can require a recent attestation to complete an assignment.
The publisher dashboard includes an assistant to invite the service account in Play Console and verify with a real token.
Testers see in their progress when a token is required.
Decode & tracking endpoints live on Tester Marketplace; your studio still owns Play Console linkage and the in-app Integrity request.

Who does what

Google runs the API on device. Tester Marketplace hosts decode & tracking endpoints. Your studio invites the service account email we provide in the assistant, integrates Play Integrity in the build testers install, and posts tokens to the campaign API — a common B2B pattern. Testers only need a compatible real Android device; they do not configure Play Console.

When not to require it

If you only need to fill a closed-testing quota once and trust your invite list, Integrity may be overkill. Start with measurable sessions/events; turn Integrity on when fraud or device trust becomes the bottleneck. See also when to require Integrity in campaigns.

FAQ

Play Integrity API? Google API to assess app environment (device/install) server-side.
Play Console app integrity? Settings and signals tied to Integrity for trusted vs altered environments.
Play Integrity pricing? Google runs the service; campaign budgets on TM are set by the publisher — see pricing.
When to require it? High fraud risk or high-trust builds; optional for low-risk quotas.

Related: Play Integrity API, Android attestation, anti-fraud beta testing, Google Play integrity, publishers guide, hire Android testers.

Pricing Integrity in closed testing Integrity in campaigns ← Publishers Hire testers →

Short definition

Why publishers use it in beta campaigns

High-value soft launches where fraud would waste budget.

Builds that must stay off unofficial sideloads.

Campaigns where telemetry alone is not enough evidence of a real device.

The three Play Integrity verdicts

Decoding a Play Integrity token on your server returns three independent verdict blocks:

Device integrity — whether the device meets Android compatibility standards and isn't rooted or tampered with. MEETS_DEVICE_INTEGRITY is the highest tier; MEETS_BASIC_INTEGRITY is a weaker environment (can include Google-certified emulators); MEETS_STRONG_INTEGRITY adds hardware-backed certification.

App integrity — whether the running APK/AAB matches what you published on Play and hasn't been modified or redistributed outside your official channel.

Account details — LICENSED if the Google account running the app has a Play licensing entitlement (installed from Play or an authorized channel), or UNLICENSED otherwise.

For tester campaigns, requiring at least MEETS_BASIC_INTEGRITY + LICENSED is typical; reserve MEETS_DEVICE_INTEGRITY for high fraud-risk campaigns (large cash rewards, real-money apps).

Common implementation mistakes

Treating a MEETS_BASIC_INTEGRITY verdict as a failure — it isn't; it just signals a lower trust tier (common on Google-certified emulators used by legitimate testers).

Checking the token only on the client. Verdicts must be decoded and their signature validated on your server; trusting a boolean returned by the client itself defeats the protection.

Not validating the requestHash / nonce against the one your backend generated — without that check, a valid token from another session can be replayed.

Hard-blocking testers on rooted devices or outdated Play Store versions with no fallback: for testing campaigns (unlike real-money production), logging the verdict and deciding case-by-case usually beats an automatic rejection.

Inside Tester Marketplace

Publishers can require a recent attestation to complete an assignment.

The publisher dashboard includes an assistant to invite the service account in Play Console and verify with a real token.

Testers see in their progress when a token is required.

Decode & tracking endpoints live on Tester Marketplace; your studio still owns Play Console linkage and the in-app Integrity request.

Who does what

FAQ

Play Integrity API? Google API to assess app environment (device/install) server-side.

Play Console app integrity? Settings and signals tied to Integrity for trusted vs altered environments.

Play Integrity pricing? Google runs the service; campaign budgets on TM are set by the publisher — see pricing.

When to require it? High fraud risk or high-trust builds; optional for low-risk quotas.

Related: Play Integrity API, Android attestation, anti-fraud beta testing, Google Play integrity, publishers guide, hire Android testers.