Skip to main content
Every verification gets a reference, a unique id assigned when the check runs. The reference is how you retrieve a result later, tie a check to a support query, or store a pointer to it in your own system.

​
Retrieving by reference

A reference identifies a verification whatever its scope, so retrieval uses one endpoint for everything:
The response is the same verification resource you got when the check ran, with the same fields. Retrieving a result again does not run a new check and is not charged; it is only reading what already happened.
Store the reference against your own record of the user or transaction. It is the durable link between your system and the check, and it is what support will ask for.

​
Listing verifications

To page through your organization’s checks, use the list endpoint:
See List verifications for filtering and paging.

​
Repeated requests are new checks

Pruva does not deduplicate runs. Every POST /v1/{scope} starts a new check, gets a new reference, calls the provider, and is charged on its own. Sending the same NIN twice runs two lookups and bills twice.
There is no idempotency key. If a network error means you did not receive a response, the check may still have run and been charged. Rather than blindly retrying, treat the reference as the source of truth: if you have it, fetch it; if you do not, a single retry is reasonable, but do not retry in a loop, since each attempt is a real, billed check.

​
A safe retry pattern

1

Run the check and capture the reference immediately

Persist the reference from the response as soon as you get it, before any further processing that could fail.
2

On a missing response, retry once

If the request errored at the network level and you have no reference, one retry is reasonable.
3

Reconcile from the dashboard or list endpoint

If you are unsure whether a check ran, list recent verifications rather than re-running. A duplicate in the list tells you the first attempt succeeded.