Skip to content
View as Markdown Open in Claude Open in ChatGPT llms.txt

Download YanezYID

YanezYID performs biometric capture on the user's device. Biometric data never leaves the device — the app returns only a yid and a BLS-signed attestation to your callback.

Partner applications do not embed this app. They hand off to it with a signed deep link.

YanezYID

YANEZ COMPLIANCE INC. · Free · Utilities

Download on the App Store Get it on Google Play

Requires iOS 17.6 or later (v1.3.0) · Android 9.0 or later (v1.3.0)

Supported versions

iOS Android
Current release 1.3.0 1.3.0
Requires iOS 17.6 or later Android 9.0 or later
Package identifier com.yanez.baund ai.yanez.yid
Deep link https://yid.yanez.ai/open https://yid.yanez.ai/open
Last updated 18 August 2026 18 August 2026

Publisher: YANEZ COMPLIANCE INC.

Minimum supported version

Yanez has not yet declared a minimum supported app version — every released build is currently supported. Once a floor is set, users below it will fail the deep-link handoff rather than degrade gracefully, so it will be announced as a Breaking entry in the changelog.

Version skew across platforms

iOS and Android ship independently and are not on matched version numbers. Gate behaviour on what the callback actually returns, never on an assumed app version.

Deliver the signed deep link as an HTTPS App Link (iOS Universal Link / Android App Link). The base URL depends on the environment, and only the matching build of YanezYID claims it: the store apps above claim yid.yanez.ai; ptest.yanez.ai is claimed only by the partner-test build, which is not on the stores — ask your Yanez contact for it.

Environment DEEP_LINK_BASE
Production https://yid.yanez.ai/open
Partner test (ptest) https://ptest.yanez.ai/open

If YanezYID isn't installed, or the installed version hasn't claimed the domain yet, the link falls back to the App Store or Google Play instead of failing silently. See Deep Link Signing for the full format.

Custom scheme (deprecated)

The yanezbio:// custom scheme is deprecated: it still resolves, but it fails silently when the app isn't installed. Migrate to the HTTPS form. For existing integrations, production builds register yanezbio://sign on both platforms. Test schemes are not symmetric across platforms:

Build iOS scheme Android scheme
Production yanezbio://sign yanezbio://sign
Dev yanezbio-dev://sign only yanezbio://sign (also yanezbio-dev://sign)
Partner test yanezbio-partner://sign only yanezbio://sign (also yanezbio-partner://sign)

An iOS test build registers only its suffixed scheme — yanezbio://sign does nothing on it. Every Android flavor accepts yanezbio://sign; use that on Android. Whatever base you deliver, the signature covers the link exactly as delivered — see Signing.

Use this to confirm the app opens and rejects an unsigned link before you wire up your backend signer.

An unsigned link should open the app and be rejected. With your real app_id the message is "Untrusted signing request"; with an app_id the app cannot look up (unregistered, or registered in the other environment) it is "This signing request could not be verified". Either rejection is the successful outcome of this step — it proves the link resolved and signature enforcement is active. If the link opens the store instead, the app isn't installed or hasn't claimed the domain yet (see Troubleshooting).

https://ptest.yanez.ai/open?message=eyJ2IjoxfQ&callback=https%3A%2F%2Fexample.com%2Fcb&method=redirect&request_id=00000000-0000-0000-0000-000000000000&event=enroll&description=Link+test&app_id=ptr_your_id

adb shell am start -a android.intent.action.VIEW -d "https://ptest.yanez.ai/open?..."

xcrun simctl openurl booted "https://ptest.yanez.ai/open?..."

Render the link as a QR code and scan it with the device camera, or host it on an HTTPS page you control and tap it.

The deprecated custom scheme opens the same way with yanezbio://sign?... in place of the HTTPS base (yanezbio-dev://sign?... or yanezbio-partner://sign?... for the iOS dev and partner builds — see the table above). Pasting a custom scheme directly into a mobile browser address bar is unreliable.

Generate a properly signed link with your backend — see Deep Link Signing — and open it the same way. The app should now show your description and proceed with the flow.

3. Confirm the callback lands

method What arrives
post A JSON POST to your callback URL from the phone. Return 2xx; anything else is shown to the user as a failed signing.
redirect The same fields as query parameters on your callback URL, opened on the phone.

There is no callback-domain allowlist on either platform — post works against your own backend from the first test. See Delivery Modes.

Troubleshooting

Symptom Cause
Nothing happens when a custom-scheme link opens App not installed, or the scheme does not match the installed build flavor (see the deprecated custom-scheme table above). Switch to the HTTPS App Link, which falls back to the store instead.
HTTPS deep link always opens the store, even with the app installed The installed app version hasn't claimed the DEEP_LINK_BASE domain yet (App Links / Universal Links). Expected until the user updates to an app version that supports it — not an integration bug on your side.
"Untrusted signing request" app_sig is missing, malformed, or does not verify against your registered public key — most often because it was computed over a different base than the one delivered. Also shown when app_id or another required parameter is absent.
"This signing request could not be verified" The app could not fetch keys for app_id: not registered in this app's environment (ptest partner_id on the production app, or vice versa), no active key, or the device is offline.
App opens but no callback arrives The phone could not reach your callback URL, or your endpoint returned a non-2xx status. Check your server logs for the POST and its response code.
Signature verifies locally but not in the app app_sig must be the last parameter, signed over the link exactly as delivered (same base, no re-ordering or re-encoding) — see Signing.