Skip to main content
Every check on Pruva, whatever the scope, follows the same lifecycle. Understanding it once means you understand all of them, because a NIN lookup, a face match, and an AML screen differ only in their inputs and results, not in their shape.

​
The lifecycle

1

You send a request

A POST to the scope’s endpoint, for example POST /v1/nin, with that scope’s inputs as the JSON body.
2

Pruva checks the gate

We confirm your key is valid, your organization is approved, the scope is active for you, and your wallet can cover the check. If any of these fail, nothing is charged and you get a clear reason.
3

Pruva calls the provider

We route the request to the provider configured for that scope, using your organization’s credentials and pricing, and wait for their answer.
4

Pruva records the result

The answer is stored as a verification with a unique reference. Any images are moved to secure storage and replaced with links, never kept in the record itself.
5

You get the result

The verification comes back as JSON: a status, the result details, and the reference you can use to fetch it again later.

​
The three outcomes

A completed check resolves to one of three statuses:

found

The record exists and matched. The result object carries the details.

not_found

The lookup ran and the record does not exist. This is a real answer, not an error.

failed

The check could not be completed, a provider timeout or outage. This is not an answer about the subject.
not_found and failed are different, and the difference matters for billing. not_found is a real answer the provider gave, so it is charged. failed is a breakdown on our side or the provider’s, so it is never charged. See Wallet and billing.

​
What comes back

The verification resource is the same whether you get it from the run, fetch it by reference, or list it. The core fields:
Prices are always in kobo, the minor unit, so 5000 means ₦50.00. Working in the minor unit avoids rounding errors; divide by 100 only for display.