Introduction
What Auvral does, what you integrate, and what your users experience.
Auvral verifies that the person signing up for your product is who they claim to be.
You integrate three things:
- One API call from your backend,
POST /v1/sessions, which returns a URL for one user, one time. - The hosted flow, opened at that URL. Either embedded with the web SDK or opened as a plain link. You do not build a capture experience.
- A webhook endpoint, which is how you find out what happened. See Webhooks.
The identity verification process
Your user photographs their ID document and takes a selfie. Auvral runs its identity verification process on those inputs and returns a verdict: verified or rejected.
That is the whole contract. Your backend never handles an image, a document number or a face. It creates a session, and later receives a signed webhook.
- POST /v1/sessionsYour backend Auvral
- sessionId, urlAuvral Your backend
- Open the urlYour backend Your user
- Completes the verification processYour user Auvral
- Webhook: verification.startedAuvral Your backend
- Webhook: verification.submittedAuvral Your backend
Webhook: verification.succeeded or verification.failed
Auvral Your backend
The URL is for one person and expires quickly. Create the session at the moment you are about to show it, not in a batch ahead of time. Do not forward it, share it or reuse it for a second user.
Identifying your user
Two values come back in every webhook:
sessionId, returned when you create the session. Store it against your user.referenceId, your own identifier for the person (typically your own user id). Auvral stores it and echoes it back untouched, and when you send none it assigns one.
Either one tells you which of your users an event belongs to.
Environments
Every organization has two API keys, and the key is the only thing that selects an environment:
| Prefix | Environment | What it does |
|---|---|---|
sk_auvral_test_ | Sandbox | Exercise the whole flow without producing real verifications |
sk_auvral_live_ | Live | Real users, real verdicts |
There is no environment parameter anywhere. See Authentication.
Reading from your backend
Two reads complete the surface, both with your API key:
GET /v1/sessions/{sessionId}: where a session got to, in five values. It keeps answering after the session expires, rebuilt from the verification.GET /v1/verifications/{id}: one verification's status, times, yourreferenceIdand yourmetadata.
They are for reconciling, not for waiting. Webhooks are still how your backend learns an outcome: make your webhook handler the place where business state changes, and make it idempotent. Then use these when a delivery is missing, when a nightly sweep finds a session you never heard back about, or when support asks about one user. Nothing arrives sooner because you asked in a loop.
Next
- Quickstart: a verified test user in about ten minutes.
- Authentication: where keys come from and how to rotate them.
- Web SDK: embedding the flow in your page.