VERIFY · IN YOUR OWN PRODUCT
One server route and one script tag.
Prove a customer meets an age requirement in about five seconds, without learning who they are, and without ever storing a date of birth. You receive one boolean per claim you asked for, signed by ORBIS, bound to your relying-party id and to your own order reference. If your use case needs to know who, this is the wrong product — and that is a property, not a limitation.
What you receive, and what you structurally cannot
Per claim asked: one signed boolean. Not received, ever: a name, a date of birth, a document, a photo, an address, a credential, or any identifier of the person. You cannot recognise the same customer across two visits — and neither can we help you to. There is nothing to leak from a record that was never sent.
The integration, in its entirety
1 Register your relying party — POST /v1/verify/rp with your origins; keep the server-side API key server-side. Your rpId comes back from GET /v1/verify/rp.
2 Open a session from your server — POST /v1/verify/session with the claims you need and your own order reference.
3 Drop the script tag on your page; it walks the customer through presenting from their wallet.
4 Fetch and verify the result — GET /v1/verify/session/{id}/result, checked against /v1/verify/jwks.json. This is the only function whose true means anything.
The /v1/verify/* plane is real platform code, mounted before the
authenticated admin plane — the checking path crosses no login and builds no record of
where a person verified.
Before you wire it in.
The verify plane is live platform code and the fixtures it is scored against are published. One honest constraint for developers: API keys are organization-scoped — there is no personal developer key yet, so credentials for integration come through a tenant.
- LIVE Publishes deterministic vectors a third party can recompute offline to check their implementation against ours conformance-vectors
- PLANNED A wallet a person installs from an app store. wallet-native You cannot hold a credential on a phone you own. Everything a person would do with a proof waits behind this.
The register holds 17 live · 2 partial · 2 planned · 5 not yet.
2 of the 4 capabilities this page depends on have no row in the register yet, so this page will not print a state for them. They are named rather than dropped, because a slice that silently shortens itself is the same defect as a claim with no receipt.
- hosted-verification
- selective-disclosure
The register route serves, but it carries no row for these yet. List what it does carry:
curl -s https://id.orbis.id/api/site/register | jq -r '.entries[].slug'