# personal_number_required

> Personal number missing

- Status: 422 Unprocessable Entity
- Returned by: /api/public
- Operations: [createOrder](https://developers.rivr.io/reference/api-public/createOrder.md)
- Retry (`retryWhen`): `after_fix`
- Did anything happen? (`outcome`): `none` (It did not happen)
- Creating an order in /api/public
- Page in the portal: https://developers.rivr.io/errors/personal_number_required
- Try it: `GET https://developers.rivr.io/errors/simulate/personal_number_required` answers with the code's exact wire form; `?succeedAfter=N&attempt=K` gives a 200 once `attempt` passes `N`

## What it means

The order has no `personalNumber`, and the clinic doesn't accept payers who aren't identified.

## What your system does

Fix the field `propertyName` points to and send the order again with the same order id. The answer carries only the first rule that broke, so the next call can get another code. The guide Patients who can't be identified shows when Rivr requires an identified payer, which personal numbers can be identified and what you do when they can't.

## Is it worth retrying?

No, not without changing the call.

`retryWhen`: `after_fix`. Change the request first, as the code's page says: a value, the token, a header or a new key. Then send it.

## Did anything happen?

`outcome`: `none`. **It did not happen.** This call did not do what you asked for and changed nothing else that you can see or that concerns money. Where the code has an `outcomeNote`, it takes precedence.

## Example: /api/public

```http
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json

{
  "propertyName": "PersonalNumber",
  "message": "PersonalNumber is required",
  "errorCode": "personal_number_required",
  "code": "personal_number_required",
  "type": "https://developers.rivr.io/errors/personal_number_required"
}
```

The `title`, `detail`, `message` and `error_description` texts are exactly as the API writes them today.