# idempotency_in_progress

> The request with the key is in progress

- Status: 409 Conflict
- 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`): `same_request`
- Did anything happen? (`outcome`): `unknown` (Unknown)
- Idempotency-Key in /api/public
- Page in the portal: https://developers.rivr.io/errors/idempotency_in_progress
- Try it: `GET https://developers.rivr.io/errors/simulate/idempotency_in_progress` answers with the code's exact wire form; `?succeedAfter=N&attempt=K` gives a 200 once `attempt` passes `N`

## What it means

A request with the same key is still being processed, or it finished without its answer being saved. In that case the change may already have been made, that is the refund, the cancellation, the send to the device or the subscription, and this answer lasts until the key expires after 24 hours. 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

Try again after `Retry-After` with the same key: once the first request has finished, you get its answer. If the answer lasts more than a few minutes, check the order or the subscription before you try with a new key, since the change may have been made.

## Is it worth retrying?

Yes. The same call can succeed in a while.

`retryWhen`: `same_request`. Send the very same request again, unchanged: the same `Idempotency-Key` and the same order id. Wait `Retry-After` seconds when the answer has the header, otherwise a short while that grows with each attempt.

## 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.

This request changed nothing. The earlier request with the same key may have made the change: refunded the order or queued the refund, cancelled the order, sent it to the device, or created or extended the subscription; it may also still be running, or have stopped before it wrote anything. The answer doesn't tell these apart.

Read the state (`resolveWith`):

- `refundOrder` → [`GET /api/public/orders/{orderId}`](https://developers.rivr.io/reference/api-public/getOrder.md): First retry with the same key after `Retry-After`. If the `409` persists: `status` 8 (Refunded) or 32 (Cancelled) means done, and 4 (Completed) can still mean a card or Swish refund on its way.
- `cancelOrder` → [`GET /api/public/orders/{orderId}`](https://developers.rivr.io/reference/api-public/getOrder.md): First retry with the same key after `Retry-After`. If the `409` persists: `status` 32 (Cancelled) means done.
- `sendOrderToDevice` → [`GET /api/public/orders/{orderId}/status`](https://developers.rivr.io/reference/api-public/getOrderStatus.md): First retry with the same key after `Retry-After`. If the `409` persists for more than a few minutes: 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): First retry with the same key after `Retry-After`. If the `409` persists for more than a few minutes and 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 409 Conflict
Content-Type: application/json
Retry-After: 1

{
  "propertyName": "Idempotency-Key",
  "message": "A request with the same Idempotency-Key is still being processed. Retry shortly with the same key to get its response. If Rivr was interrupted while processing it, this answer can last for up to 24 hours. If it persists for more than a few minutes, check the order or subscription before you retry with a new key.",
  "errorCode": "idempotency_in_progress",
  "code": "idempotency_in_progress",
  "type": "https://developers.rivr.io/errors/idempotency_in_progress"
}
```

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