Skip to main content

Relying Party integration

This section describes how a backend system (Relying Party, RP) integrates with the Attestation API.

Role of the Relying Party​

A Relying Party (RP) is any backend system that needs assurance that a request originates from a genuine, untampered mobile app running on a real device. The RP does not perform attestation itself — instead, it delegates verification to the Mobile Attestation API and consumes the result.

In a typical flow, the RP:

  1. Decides when attestation is required — for example, on login, on sensitive transactions, or on app start.
  2. Coordinates the nonce — either by requesting one from the Attestation API (session approach) or by generating its own (sessionless approach). See Nonce generation.
  3. Passes the nonce to its mobile app as part of the RP's own protocol.
  4. Receives the attestation token the device produces and forwards it to the Attestation API for verification.
  5. Acts on the verification result — granting or denying the request, raising risk signals, or logging the outcome.

The RP never inspects the attestation token contents directly and never communicates with the attestation issuers (Google Play Integrity, Apple App Attest). All cryptographic validation, replay protection, and platform-specific checks happen inside the Attestation API.

Prerequisites​

Before integrating, an RP needs:

  • An API key issued by the Attestation API operator. Keys have the form xma_[random] and are sent in the X-Api-Key header on every request. See Authentication.
  • An Attestation API base URL — the RP must not hardcode a single URL.
  • A nonce strategy decision — session or sessionless. The choice affects which API calls the RP makes and what data it must persist between calls. See Nonce generation.