For developers

Build on proof, not claims.

Let people sign in with Vaurse and share facts that were signed at the source, with their say-so. No more uploading certificates or checking them by hand.

OAuth 2.1 and OpenID Connect, W3C Verifiable Credentials, OpenAPI 3.1, signed webhooks.

Illustrative
$ curl https://api.vaurse.com/verify/cards/441720905518

{
  "card": "VOS 4417 2090 5518",
  "status": "active",
  "issuer": {
    "name": "Kasa Logistics",
    "tier": "verified"
  },
  "current": { "relationship": "employed" }
}
What you can build

Six things, from sign-in to doors.

  • Sign in with Vaurse

    People sign in with the app they already have.

  • Check a Voscard number

    Real and active, frozen, or not found.

  • Ask for a signed fact

    A job, a degree or a certificate, with the person's consent.

  • Issue signed facts

    For schools, employers and bodies.

  • Accept Voscards at doors and tills

    Readers and the till app.

  • Get told when something changes

    Webhooks, for example a card frozen or a fact withdrawn.

How consent works

The person says yes or no.

  1. Your app asks for specific facts.
  2. The person sees exactly what's asked and says yes or no in the Vaurse app.
  3. You get only those facts, signed, and the person can see you asked.
Sign in with Vaurse

A login button that brings proof with it.

  • Standard OpenID Connect with PKCE. If you've added "Sign in with Google", you know the shape.
  • The person approves in the Vaurse app, with their phone's own Face ID or fingerprint. No password to store.
  • Check every claim yourself against the issuer's published keys.
Illustrative
GET https://api.vaurse.com/oauth/authorize
  ?response_type=code
  &client_id=app_kasa_hr
  &redirect_uri=https://hr.kasa.example/callback
  &scope=openid profile employment:read
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8U
  &code_challenge_method=S256

Real endpoints, scopes and field names are in the docs.

Signed facts, with consent

Ask for exactly what you need. Nothing more is possible.

Layer 1

Public

Is this card real and active? Free, no account.

Layer 2

What they share

Verified claims the person switches on.

Layer 3

The record

For a named requester, a stated purpose and a set time.

  • Four scopes, and only four: employment, education, licences and certifications, and right to practise.
  • The person approves scope by scope. "Education yes, employment no" is a valid answer.
  • You get issuer-signed entries, each showing who signed it and when.
11:204G
Sign in with Vaurse
Kasa Jobs would like to see:
Your name
Your degree
Signed by Osu Institute of Technology
Your last job
Signed by Kasa Logistics
NoYes, share
Check a Voscard

Real, active, and who says so. In one call.

Is this card real and valid, and is the person still employed or enrolled where it says? Every answer shows the issuer's tier, and works offline from a signed QR.

Illustrative
GET https://api.vaurse.com/verify/cards/441720905518

200 OK
{
  "status": "active",
  "issuer": { "name": "Kasa Logistics", "tier": "verified" }
}

Sandbox cards are fictional. Real field names are in the docs.

Webhooks

Know the moment something changes.

  • Signed with HMAC-SHA256, with a timestamp and replay protection.
  • A card frozen or revoked, a fact withdrawn, a visitor arriving: you hear at once.
  • Only what you need. A code event never says who got the code.
Illustrative
POST https://hr.kasa.example/hooks/vaurse
Vaurse-Signature: t=1790812800,v1=5257a8…

{ "type": "card.frozen", "data": { "card": "441720905518" } }
Delivery log
08:52card.frozen200
08:40card.tapped200
08:31visit.arrivedRetrying
Sandbox · Test cardsTest keys
Test personCardAnswer
Test Person AVOS 4821 5518 2090Real and active
Test Person BVOS 7114 0027 3308Frozen
No oneVOS 3056 2291 8475Not found
Test Student CVOS 6630 1847 5521Real · student
Test Person DVOS 2209 7763 0418Left the organisation
Test calls never reach a real person.Sandbox
Test before you go live

A sandbox with test cards and test people.

Separate keys for test and live.

Going live

Live keys come after a review. That's the point.

  1. Build in the sandbox.

    Fictional people, cards and doors.

  2. Verify your organisation.

    Against the company register and your domain.

  3. Apply to go live.

    Your use case, a data processing agreement and a security questionnaire.

  4. Review.

    Every live key comes after a go-live review.

  5. Live keys.

    With two-factor on.

The rules

What every app agrees to.

  • Only what the person allows.
  • Every request shows in the person's app.
  • You may not sell or pass on what you receive.
  • Keys are yours to keep safe; rotate them any time.
Pricing

Free to start in the sandbox.

For live use, talk to us.

Do people need a Voscard? +

They need the Vaurse app; it's free.

Can we issue facts ourselves? +

Yes, if you're the one who knows: an employer, a school, a licensing body.

Where's the documentation? +

In the developer docs. Read the docs.

For developers

Start in the sandbox.

  • Test cards and test people
  • Separate test and live keys
  • Go-live review when you're ready
Sandbox
Illustrative
// sandbox.vaurse.com
const card = await vaurse.verify("441720905518");
card.status   // "active"
card.issuer   // "Kasa Logistics (test)"

Real endpoints and field names are in the docs.