Integrating platforms
Give your customers non-repudiable approvals — under your brand.
A payroll service, a treasury tool, a signing workflow: your product already has the users, the UI and the moment where someone must commit to something irreversible. INTYGA supplies the missing piece — a passkey signature bound to the exact bytes, with a tamper-evident record behind it — white-label. Your users never hold an INTYGA account and never see an INTYGA page: every ceremony runs on your own domain. And because your requests carry your customers' financial or personal data, INTYGA receives a digest of each payload, never the payload.
The integration point
You provision subjects — your users, named by an opaque id you choose. Who that id belongs to remains your claim: you attach the identity-assurance metadata (how you verified the person), and it is recorded and witnessed verbatim, never asserted by INTYGA.
- Register your domain as a Relying Party and enroll each user's passkey from your own page — your backend relays the ceremony, INTYGA verifies it against your registered origin.
- To sign, canonicalize your payload once, hash it, and relay the signing ceremony. The user's passkey signs over the digest, your RP identity, the subject, and the moment.
- Verify the receipt in your own service, against the digest you recompute and the keys you enrolled — no call to INTYGA, no INTYGA secret.
The credential scoping does real work here: a passkey enrolled under your Relying Party is cryptographically bound to it by the browser and the authenticator themselves. A staging RP and a production RP can never vouch for each other, and nothing enrolled anywhere else can sign for you.
Behind every receipt sits the witness ledger: enrollment, revocation, each signature and each refusal land as committed, hash-chained entries, and a receipt carries its ledger position so its inclusion proof can be fetched and checked against anchored roots. INTYGA holds no key capable of producing a valid approval — the evidence does not depend on trusting us.
What the receipt proves — and what stays yours
A platform receipt attests that this enrolled key signed this digest at this time, on this Relying Party. It deliberately does not attest what your UI displayed — that guarantee moves to you, and keeping it is one rule: render the approval screen and execute the action from the same canonical serialization you hashed. The developer guide walks through exactly this discipline, because a platform that rebuilds its payload between approval and execution has a receipt that proves nothing about what ran.
Build against test mode, ship against the same API
Mark a Relying Party as test mode and everything stays fully real — real ceremonies, real receipts, real ledger entries — but nothing is billed and nothing counts toward usage. Test mode is loopback-only (localhost, 127.0.0.0/8, or::1); reserved and private-DNS names can serve real users, so shared staging RPs are registered live. The API stays the same when you ship. A runnable demo platform ships in the repository, exercising the whole loop against a local gateway with a real browser passkey or headlessly.
Metered on outcomes, priced flat.
Every completed signature is one Protected Op — the same unit everything else meters — visible per Relying Party in your billing view, with requests, declines and expiries free. INTYGA never refuses an approval because you crossed a plan-volume allowance, and Protected-Op volume is not billed; the free tier is enough to build and demonstrate the entire integration.
Read the integration guide →