Purge a verification

The verification's id.

How verifications on this workflow are conducted. hosted: the person being verified walks the journey on our screens and submits it. staged: you create a verification, upload each document against the step it answers, and then ask for the checks to run. instant: you send the whole submission in one request, which runs the checks and answers with the finished record.

A workflow is one of the three, and every endpoint belonging to another is refused on it.

open while the run is live and the user may act, which a step held up by a technical problem does not end; submitted once the user has finished, which they can only do with every step settled, so the result is final from that moment; completed once the checks that follow a submission have run, such as notifying you by callback, and the data is safe to read; failed if the run reached an unrecoverable state, in which case reset it or create a new one; cancelled if you ended the run; gated if a check this workflow puts to a system of yours stopped the journey there, which ends the run where it stood. A check stops it when your system answers terminate or redirect, or when your system gave no answer and the workflow falls back to terminate. Poll until the status is one of completed, cancelled, gated or failed.

expired supersedes all of them once the retention window runs out: the run is of no further use and is kept for your audit alone. It says nothing about how the run had ended, so read completed_at, cancelled_at, gated_at or failed_at for that rather than expecting the status to hold it.

The workflow this verification runs.

Which version of the workflow this verification runs. It is the workflow's latest version when the verification was created, and it holds for the verification's whole life: a change published to the workflow afterwards never changes what this verification asks for, which steps it reports or the names its outputs arrive under. Resetting the verification moves it onto the latest version at the time.

The user's mobile number, as you provided it. Null on a verification you supplied yourself, and null once the verification has expired.

Your identifier for this verification, echoed back.

Where the user is sent after submitting, where one was given.

Where to send your user, on a hosted verification. The same address serves every user of this workflow and carries no credential, so it is safe to send over WhatsApp, SMS, or email, and the user proves who they are by signing in with the mobile number you created the verification with. To open the journey from inside your own app with the user already signed in, create a handoff instead.

Null on a verification you supplied yourself, which opens no journey.

When the verification was created.

When you asked for the checks to run, on a staged verification. From that moment the submission is frozen: uploads, withdrawals and a run request with different values are refused until you reset.

On an instant verification it is when the request carrying the whole submission arrived. Null on a hosted one, and null on a staged one until you ask.

When the verification was submitted, if it has been: by the user on a hosted workflow, by the run of the checks on one you supplied yourself.

When the verification completed, if it has.

When the verification was cancelled, if it was.

When a check of yours stopped the journey, if one did.

The step whose check stopped the journey, if one did. A workflow may put more than one check to you, and this says which of them the run stopped at.

It is set and cleared with gated_at: it stays set once the verification expires or you purge it, so the record still says how the run had ended, and a reset clears both.

When the verification was marked failed, if it was.

When the verification expired, if it has. From that moment it is kept for your audit and nothing else: it holds what each step concluded and nothing the user gave, so no answers, no values read off their documents, and no files. The step states you read are the ones frozen at that moment. Read the other timestamps to see how it had ended before it expired.

What expired the verification. retention when its workflow's retention window ran out; client when you purged it. Null until it expires.

When the verification was last acted on: by the user on a hosted workflow, by you or by the run of the checks on one you supplied yourself. A verification that is created and never touched reads the moment it was created. expires_after_days is counted from here, so the two together say when a record left untouched expires.

How many days this verification may go without activity before it expires and everything the user provided is deleted, as the version it runs states. It is this verification's own window: a later version of its workflow can state a different one, which reaches the verifications created or reset after it, so read the window here rather than off the workflow. On an expired verification it is the window it was held to.

How many credits this verification has used. A run uses one credit when it first reaches completed, cancelled or expired, whatever the workflow asks for and however many of its checks ran. A run that ends as failed or gated uses none, and one still open or submitted has used nothing yet.

Resetting a verification runs the subject through again, which is a run of its own and uses a credit of its own, so a record reset twice and completed each time reads 3.

How many times this verification has been reset. A reset clears everything the record collected and runs the subject through the checks again, so a verification reading 2 is on its third run and holds what that one has collected.

Each of these opened a run charged a credit of its own where it ended, which is what credits_consumed counts. A reset that cleared a run no credit had paid for also drew one of the workflow's resets: see resets on the workflow.