Mobile link data
A mobile-enabled link can return:
Unknown query parameters are discarded. Dynamic values are non-empty scalar strings of up to 256 characters. At most 20 dynamic keys may be allowed; each key begins with a lowercase letter, contains only lowercase letters, digits, or underscores, and is at most 40 characters.
Static referral data wins. If the link has no static referral code and
ref is an allowed dynamic key, the allowed ref value can supply the referral code. Other unknown or unapproved query values never appear in the attribution response.
Safe metadata limits
Safe metadata must be a JSON object, not an array or string. It supports at most 20 top-level keys, three nested levels, 4 KB after encoding, and strings up to 1,000 characters. Do not include credentials, authentication values, cookies, payment-card data, government identifiers, email addresses, phone numbers, or health information. Biqli rejects keys that indicate sensitive fields. Use metadata for bounded routing or campaign context, not for authorization. Your backend must decide whether a user is eligible for a reward.First-open state
The SDK creates a random app-instance ID and starts a 24-hour first-open recovery window. During that window it can preserve a pending opaque handoff and the exact idempotent request across process restarts. The first accepted install attribution is immutable for that app installation. RepeatingfirstOpen: true for the same app instance returns the accepted install result instead of replacing it with a later click.
Both SDKs cache a matched first-open result. Android also completes and caches a
clean no-match after Google Play Install Referrer reaches a terminal empty or
unavailable result. A later cold launch with no new App Link returns the
applicable cache without creating another mobile-open event. An unmatched iOS
installation remains eligible for recovery during its 24-hour first-open
window. Every cached result deliberately excludes the short-lived signed
receipt.
Retry behavior
Each live resolver call makes at most three immediate attempts. The SDK uses short bounded backoff with jitter for transport failures, rate limits, and server failures. It does not run an autonomous ten-attempt background job. If all immediate attempts fail, the SDK keeps the pending request in protected local storage. Call resolution again on a later cold launch to retry with the same event ID and idempotency key. Keep application startup non-blocking and handle a temporary error as recoverable. Validation, authentication, permission, handoff-mismatch, and other terminal client errors are not retried as transient failures.Reinstall behavior
Android application data removal normally creates a new encrypted store and app-instance ID. On iOS, the SDK combines Keychain state with an installation marker that is removed during uninstall; if the marker is absent after reinstall, it clears prior SDK state and creates a new app-instance ID. A reinstall can therefore begin a new first-open lifecycle. It cannot claim an opaque handoff that another installation already accepted.Resolution priority
The resolver applies this order:- Validate the mobile app, platform, headers, body, and exact inputs.
- Resolve an eligible opaque handoff or installed-app link.
- Reject the request if both exact inputs identify different links.
- If no exact match exists, evaluate opted-in iOS probabilistic matching for an eligible first open.
- Return
nonewhen no eligible match exists.
Analytics meanings
The Mobile App detail page reports the last 30 days:
Recent events show the match type, confidence, first-open flag, SDK version, and event time. Mobile resolution currently appears through the SDK/API response and these analytics; there is no mobile-open webhook.
Server-side proof
Client attribution helps route the app, but it is not sufficient proof for a financial reward or privileged action. Send the liveattributionReceipt to a trusted backend and follow Verify attribution receipts.