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

# Errors and testing

> Interpret API errors and test an Inflow integration safely.

# Errors and testing

All endpoints return JSON. Successful resource responses are generally wrapped in `data`; paginated responses also include `meta`. Errors return a message that is safe to log and show in an appropriate user-facing form.

## Error format

```json theme={null}
{
  "message": "Invalid or expired API key"
}
```

## Common responses

| Status        | Meaning                                                                      | What to do                                                                             |
| ------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| `400`         | Invalid input or an operation is not allowed in the resource's current state | Correct the request. For payments, check the current status before retrying.           |
| `401`         | Key missing, invalid, or expired                                             | Confirm the `Authorization: Bearer gtw_sk_...` header and environment.                 |
| `403`         | Organization inactive or key lacks the required permission                   | Use a permitted key or update the key's scopes in the dashboard.                       |
| `404`         | Resource does not exist in the organization associated with the key          | Confirm the ID and that sandbox and production data are not being mixed.               |
| `409`         | Duplicate unique value, such as a payment reference or customer email        | Reuse the original resource or generate a new reference for a genuinely new operation. |
| `500` / `502` | Temporary server or upstream-provider problem                                | Record the request context and retry only after reconciling the operation.             |

## Build a safe retry policy

For a timed-out create request, do not blindly issue the request again. First search your application records using the customer email or your generated payment `reference`. A payment reference must be unique, which makes it a useful idempotency key in your system.

```ts theme={null}
const reference = `order_${order.id}`; // Store this before calling Inflow.

// If the network times out, query your own order by reference first.
// Create a new payment only if no prior payment was recorded.
```

## Test in sandbox

1. Use the sandbox base URL and a sandbox API key.
2. Create a test customer with an email address not already used in that sandbox organization.
3. Create a payment with a clearly identifiable test reference, such as `test_order_001`.
4. Complete the provider's sandbox flow, then retrieve the payment by ID and check its status.
5. Check wallet balances and payout behavior only with sandbox-safe accounts and data.

Keep test references and IDs out of production workflows. Sandbox and production environments are isolated: an ID or key from one will not work in the other.