Skip to main content
Mobile deep linking is in Public Beta. Complete your own privacy, consent, and abuse review before enabling it for customers.

​
Keep the three credentials separate

Never put a secret workspace API key in a mobile binary. A mobile publishable key is intentionally distributable, but it is app-scoped and rate-limited; rotate it when exposed outside the expected application context.

​
Treat routes and attribution as untrusted input

  • Allow only known routes and parse route parameters defensively.
  • Do not make a Universal Link perform destructive or privileged work without normal authentication and confirmation.
  • Discard unknown dynamic keys and reject unexpected values.
  • Keep personal, authentication, payment, and health information out of safe metadata and referral codes.
  • Do not log raw opaque handoff URLs, mobile keys, signed receipts, or complete resolver payloads.
The server stores handoff tokens in a non-reversible form. The SDK may temporarily keep the opaque token in protected local storage so an offline first launch can retry.

​
Verify rewards on a trusted backend

The live resolver can return a ten-minute Ed25519-signed compact JSON Web Token (JWT). Before granting a reward, your backend must:
  1. retrieve Biqli’s JWKS from https://biq.li/.well-known/biqli-attribution-jwks.json;
  2. select the public key whose kid matches the JWT header;
  3. require alg: EdDSA and typ: JWT and verify the Ed25519 signature;
  4. require the expected issuer and your exact Mobile App ID as the audience;
  5. validate nbf, iat, and exp using a small clock-skew allowance;
  6. compare appId, openId, clickId, linkId, matchType, confidence, and attribution with the operation you are authorizing; and
  7. consume jti idempotently so the same receipt cannot grant the reward twice.
Never grant a reward from a referral code or client response that your backend has not verified. A cached SDK result has no receipt and must not be treated as fresh proof. Set the SDK’s consent-required option when local law or policy requires affirmative consent. Until the caller supplies consent, the SDK does not query Google Play Install Referrer or contact Biqli. Probabilistic iOS matching is separately disabled by default. Enable it only after reviewing your legal basis, disclosures, retention needs, and the risk of a probabilistic result. It requires an attached verified domain, an eligible first open, explicit SDK opt-in, and granted consent. Ambiguity produces no match.

​
Platform privacy behavior

The mobile SDKs do not request or use Apple’s Identifier for Advertisers (IDFA), Android Advertising ID, location, contacts, or storage permission. The Android package requests only internet access. The iOS package includes a privacy manifest and never silently reads the pasteboard; exact deferred handoff requires a person to operate a paste control. Review the package source and privacy manifest as part of your application privacy declaration:

​
Retention and minimization

Send only the fields required for attribution. The SDK treats the installation as first-open eligible for up to 24 hours. A failed network request can remain pending for an idempotent later-launch retry, but it does not extend first-open eligibility or the handoff’s expiry. A configured handoff can expire within its allowed 15-minute to seven-day lifetime, and an expired handoff cannot be newly claimed. Biqli’s service-side retention is governed by the applicable account terms and privacy documentation. Do not infer or promise a service retention period from client caching behavior.