> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pruva.com/llms.txt
> Use this file to discover all available pages before exploring further.

# References and retrieval

> How to fetch a verification again, and what to know about repeated requests.

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.

```json theme={null}
{
  "reference": "43817179a3dc8c341d358432b0590924",
  "scope": "nin",
  "status": "found"
}
```

## Retrieving by reference

A reference identifies a verification whatever its scope, so retrieval uses one endpoint for everything:

```bash theme={null}
curl https://api.pruva.africa/v1/verifications/43817179a3dc8c341d358432b0590924 \
  -H "X-Pruva-Key: pruva_live_YOUR_KEY"
```

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.

<Note>
  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.
</Note>

## Listing verifications

To page through your organization's checks, use the list endpoint:

```bash theme={null}
curl https://api.pruva.africa/v1/verifications \
  -H "X-Pruva-Key: pruva_live_YOUR_KEY"
```

See [List verifications](/api-reference/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.

<Warning>
  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.
</Warning>

## A safe retry pattern

<Steps>
  <Step title="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.
  </Step>

  <Step title="On a missing response, retry once">
    If the request errored at the network level and you have no reference, one retry is reasonable.
  </Step>

  <Step title="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.
  </Step>
</Steps>