> For the complete documentation index, see [llms.txt](https://docs.talsec.app/appsec-articles/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.talsec.app/appsec-articles/articles/how-to-combine-appicrypt-and-play-integrity.md).
# How to Combine AppiCrypt and Play Integrity
AppiCrypt and Play Integrity are complementary products with a small overlap, but a big advantages on the side of AppiCrypt stemming from RASP+ core. Let's learn how to bind both to one API request.
### ⚡Key takeaways:
* **🔗 Verifying two security verdicts independently gains you almost nothing. Binding them to the same request gains you a property that neither has alone.**
* 🧬 They answer **different questions**. AppiCrypt: *what is happening inside this runtime, on this request, right now?* Play Integrity: *what does Google think of this device and this install?*
* 🚫 Binding kills **mix-and-match** — pairing a Play Integrity token minted on a compromised device with a cryptogram from a clean one. Both bring different security claims. The pair has them all.
* ⚖️ **Disagreement is a signal.** "Google says certified, the Talsec says hooking" is the strongest evidence you will get that your app is being targeted specifically.
* 💰 Order your checks **cheapest-first**. Verify AppiCrypt before you spend Play Integrity quota💬
The full wire format and verification algorithm ship as a **blueprint with AppiCrypt**. Questions about your own endpoints? [**info@talsec.app**](mailto:info@talsec.app)
{% hint style="info" %}
**👋 A word before we start**
We build [**AppiCrypt®**](https://docs.talsec.app/premium-products/product/appicrypt) at Talsec and we spend our days inside app attestation: what the verdicts actually mean, where they hold, where they quietly stop holding, and what real fleets of devices look like when you measure them.
This three-part series is written for CTOs, backend architects and mobile developers who have to decide what a cryptogram or Play Integrity verdict does actually mean.
**Explore the complete series:**
* **Part 1:** How Attackers Exploit Play Integrity API and Where AppiCrypt Fits — what Play Integrity does well, where its limits are, and the seven ways real attacks get around it.
* **Part 2:** Play Integrity Fix: why AppiCrypt is the better security anchor — one bypass, in depth: a Magisk module with millions of downloads, and what it says about anchoring authorisation on a single third-party verdict.
* **Part 3:** **Combining AppiCrypt and Play Integrity** — the side-by-side model: where the two overlap, where they complement, and how to bind them to one request so neither can be swapped out.
*Disclaimer, for full transparency: this series uses Talsec technology. We are not the only vendor in mobile security — we are the one running on 2,500,000,000 devices.*
{% endhint %}
### AppiCrypt + Play Integrity Binding: The Design
The two mechanisms have **different coverage and different failure modes**. Verifying them independently gains little: you learn two facts that were already available separately. What you gain by **binding** them is something neither has on its own.
| Term | Meaning |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Binding value** | A URL-safe base64 string passed to **both** attestation producers, tying two independent verdicts to one request. |
| **Challenge** | A server-issued, single-use random value contributed to the binding value. Optional in general, required for sensitive endpoints. |
| **Attestation pair** | One AppiCrypt cryptogram and one Play Integrity token carrying the same binding value. |
| **Absence** | No Play Integrity token was supplied, or it could not be decoded, for reasons outside the caller's control. **Not** the same as a negative verdict. |
### Side by side
| | **AppiCrypt®** | **Play Integrity** |
| ----------------- | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| **Root of trust** | Talsec SDK, in your app | Google Play services |
| **Platforms** | iOS, Android, Web — no GMS dependency | Android with Google Play services only |
| **Availability** | offline-capable, no quota | needs network + Play, 10k/day default quota |
| **Cadence** | every API request | per session, or per sensitive action |
| **Tells you** | root, jailbreak, hooking, debugger, emulator, repackaging, tampering — *what is happening in the runtime right now* | unrecognised binary, uncertified device, unlicensed install, Play Protect state — *what Google thinks of this device* |
| **Who verifies** | your backend | Google, then your backend |
| **Fails when** | your SDK integration is wrong | Google is down, quota is exhausted, or the device has no Play services |
#### Where they overlap
Genuine overlap exists (unless spoofed):
* **App identity.** Both can tell you which package and which signing certificate you are talking to.
* **Basic device compromise.** A simply modified device will often — not always — fail both.
* **Install source.** Play Integrity knows whether the install came from Play. AppiCrypt sees the repackaging and tampering that frequently accompany an unofficial one.
Where they overlap, they are a **cross-check**. Where they do not, they are genuine coverage.
#### Where they complement
* **Cadence.** Play Integrity's quota makes **per-request attestation impossible** at any real scale. AppiCrypt has no quota, so every call can carry proof. Between them: *continuous* proof plus a *periodic* second opinion.
* **Runtime versus reputation.** A device can be perfectly stock, fully certified, licensed — and have Frida attached right now. Play Integrity may fail while AppiCrypt provides the real visibility into the device.
* **Platform support.** iOS and Web have no Play Integrity at all. One mental model and one backend code path across all three beats maintaining Play Integrity on Android and App Attest on iOS with different semantics to reconcile.
* **Ownership.** AppiCrypt lives entirely in infrastructure you control. When the Play Integrity server is down, you still have a decision you can build on.
### Protocol overview
Walking it through:
1. **Challenge** *(optional in general, required for anything that moves money or state)*. The backend issues a single-use random value with a TTL. Without one, the same payload always produces the same binding — so a captured attestation pair replays until it ages out. A payload-only binding proves *which* request the attestations belong to, but not *when*.
2. **Derive the binding value** from the challenge and the exact bytes of the request body.
3. **Ask both producers for an attestation, in parallel**, passing the identical string. Warm up the Play Integrity token provider *outside* the request path — at app start, or on entering the flow. Never pay that latency per request.
4. **Send one request** carrying the payload and both attestations. They travel in **headers, not in the payload**, so the body remains exactly the bytes that were hashed.
5. **Verify cheapest-first.** Structural checks, re-derive the expected binding, verify AppiCrypt — and only then exchange the Play Integrity token with Google. A request that fails early costs no quota.
6. **Cross-check and decide.** Compare the overlapping claims. Any contradiction denies. Then: allow, step up, or deny.
### The full blueprint
What this article gives you is the **generic composition**: why the two belong together, what the binding value is for, and the order the checks go in. That is enough to decide whether the model fits your architecture.
What it deliberately does not reproduce is the specification — the exact wire format and header contract, the canonical binding construction, the complete backend verification algorithm, the per-field rules for identity and freshness, the absence-handling policy, and the full cross-verdict denial matrix.
**That blueprint is shipped as part of the** [**AppiCrypt®**](https://docs.talsec.app/premium-products/product/appicrypt) **product** — so you can simply implement it rather than rediscover it.
{% hint style="success" %}
Write to [**info@talsec.app**](mailto:info@talsec.app) and we will walk your flow with you.
* [**AppiCrypt®**](https://docs.talsec.app/premium-products/product/appicrypt) — cryptographic proof of app and device integrity on every API call, verified by your own backend (Android & iOS)
* [**AppiCrypt for Web**](https://docs.talsec.app/premium-products/product/appicryptweb) — the same protocol in the browser
* [**RASP+**](https://docs.talsec.app/premium-products/product/rasp) — the runtime signals the cryptogram carries: root, hooking, debugger, emulator, tampering and more
**Plans Comparison**
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.talsec.app/appsec-articles/articles/how-to-combine-appicrypt-and-play-integrity.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
