Skip to main content

Plug VirtuALL Verify into your system.

Start checks through our API. Get results back by webhook.

Three steps to a verified customer.

  1. 01

    Create a request

    Choose the checks and the reason, from your system.

  2. 02

    The customer completes it

    In the VirtuALL app. Nothing to build on your side.

  3. 03

    Receive the result

    Posted to your webhook when it is done.

What comes back.

The outcome
Approved or declined, for each check you asked for.
The approved details
Only the fields the customer agreed to share.
The record
Purpose, checks run, consent and time, for your files.
The dashboard
Your checks, your quotes and a printable verification certificate for each customer.

API access and documentation come with onboarding.

Which checks you can request

Tell us about your stack.

We will walk your team through the integration.
Ask about integration

Questions, answered.

See all questions
How does the result reach our system?

Through our API. You start a request from your system, and the result and a record of the request are returned by webhook. We share integration details during onboarding.

Does the customer need the VirtuALL app?

Yes. The customer reviews the request and completes any checks in the VirtuALL app.

Is there a record of each check?

Yes. Each request keeps its purpose, the checks run, the customer’s consent and the outcome, so you can show why you hold a detail.

What standards is VirtuALL built on?

Credentials held by the person: Each credential is bound to its holder, and every presentation carries a fresh proof, so someone else cannot replay it. Selective disclosure: The customer approves field by field. What they leave out is never sent to you. Verifiable credential formats: Moving to SD-JWT VC under the EU HAIP profile, with mdoc for ID and licence credentials. Open issuance and presentation: OpenID4VCI for issuing and OpenID4VP for presentation, so other wallets and verifiers can take part. Proofs that answer without revealing: Predicate proofs, such as 18 or older, aligned to the EU mdoc-ZK work rather than a scheme of our own. Standards-based revocation: Credential status published as an IETF Token Status List.