# idempotency_outcome_unknown

> The outcome is unknown

- Status: 500 Internal Server Error
- Returned by: /api/public
- Operations: [cancelOrder](https://developers.rivr.io/reference/api-public/cancelOrder.md), [refundOrder](https://developers.rivr.io/reference/api-public/refundOrder.md), [sendOrderToDevice](https://developers.rivr.io/reference/api-public/sendOrderToDevice.md), [createSubscription](https://developers.rivr.io/reference/api-public/createSubscription.md)
- Retry (`retryWhen`): `never`
- Did anything happen? (`outcome`): `unknown` (Unknown)
- Idempotency-Key in /api/public
- Page in the portal: https://developers.rivr.io/errors/idempotency_outcome_unknown
- Try it: `GET https://developers.rivr.io/errors/simulate/idempotency_outcome_unknown` answers with the code's exact wire form; `?succeedAfter=N&attempt=K` gives a 200 once `attempt` passes `N`

## What it means

The request failed after the change may have been made, that is the refund, the cancellation, the send to the device or the subscription, so the outcome is unknown. The same key gets this answer for 24 hours, and the request is not repeated for it. Until the platform's next release, `message` in production says "Check the order" instead of "Check the order or subscription" on the refund and the cancellation. On send-to-device and `POST /api/public/subscriptions` the code comes only in the sandbox until the platform's next release; production ignores the header there.

## What your system does

Check the order with `GET /api/public/orders/{orderId}`, or the subscription with `GET /api/public/subscriptions/{subscriptionId}` when you have its id, before you try again with a new key.

## Is it worth retrying?

No, not without changing the call.

`retryWhen`: `never`. Don't send it again. The answer is final for this request: read the current state, the order for example, and act on that.

## Did anything happen?

`outcome`: `unknown`. **Unknown.** The answer doesn't say whether what you asked for has happened, through this call or an earlier one. Read the state first.

The change may have been made although the answer was `500`: on refund a refund that is queued and carried out later, or an unpaid order that was cancelled; on cancel an order saved as cancelled without the callback having been sent; on send to a device an order the device may have received; on a subscription request a new subscription, or an existing one that was given the payments. The same key gets this answer for 24 hours, and the request is never repeated for it.

Read the state (`resolveWith`):

- `refundOrder` → [`GET /api/public/orders/{orderId}`](https://developers.rivr.io/reference/api-public/getOrder.md): `status` 8 (Refunded): the refund is made. 32 (Cancelled): an unpaid order was cancelled. 4 (Completed) doesn't prove that nothing started: the refund may be queued, and card and Swish refunds change the order only once the payment provider confirms. Read again after a while.
- `cancelOrder` → [`GET /api/public/orders/{orderId}`](https://developers.rivr.io/reference/api-public/getOrder.md): `status` 32 (Cancelled) means the order is cancelled, even if no callback came.
- `sendOrderToDevice` → [`GET /api/public/orders/{orderId}/status`](https://developers.rivr.io/reference/api-public/getOrderStatus.md): Sending doesn't change the order, so `status` doesn't show whether the device got it. 1 (Created): no payment is done or parked, but the order may already show on the device and a payment may be under way there without the status changing, so look at the device before you send again with a new key. 2 (Pending): an invoice, bank or financing payment is under way. 4 (Completed): the order is paid. 8 (Refunded) or 32 (Cancelled): the order is refunded or cancelled. Anything but 1 answers `order_not_sendable` on another attempt.
- `createSubscription` → [`GET /api/public/subscriptions/{subscriptionId}`](https://developers.rivr.io/reference/api-public/getSubscription.md): If you have the subscription's id from before: see whether the payments in the request are in `payments`, with their `externalReference`. Without an id there is no read per person, but the same body with a new key and the same `personalNumber` puts the payments on the clinic's subscription for the person, if there is one, adds only payments whose `externalReference` isn't there already and answers with the subscription's id. This works only when every payment has its own `externalReference`: without one the payments can't be recognised, and an existing subscription gets at most one payment without a reference, none at all if it already has one, although the answer is `201`. Without `personalNumber` every request is a new customer and a new subscription, so don't send it again with a new key: another request creates a second subscription with the same payments, and `/api/public` has no way to find the first. Contact Rivr with the time of the request.

## Example: /api/public

```http
HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{
  "propertyName": "Idempotency-Key",
  "message": "The request failed after the change may have been made, so its outcome is unknown. The request is not repeated for this Idempotency-Key. Check the order or subscription before you retry with a new key.",
  "errorCode": "idempotency_outcome_unknown",
  "code": "idempotency_outcome_unknown",
  "type": "https://developers.rivr.io/errors/idempotency_outcome_unknown"
}
```

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