# Idempotency-Key on send-to-device and POST /api/public/subscriptions, in the sandbox

- Date: 2026-11-02
- Type: New
- Surface: /api/public
- What you need to do: Nothing.
- Address: https://developers.rivr.io/changelog/2026-11-02-api-public-idempotency-send-to-device-subscriptions

`POST /api/public/orders/{orderId}/send-to-device` and `POST /api/public/subscriptions` accept an optional `Idempotency-Key` header, the same way the refund and the cancellation do: 1 to 255 printable ASCII characters, a new value for every send or subscription request and the same value when you retry that very request. The first `2xx` answer is stored for 24 hours and is sent again, with `Idempotent-Replayed: true`, for the same key and the same request, so a retry after a lost answer does not send the order to the device a second time, nor create or extend the subscription a second time. An answer that refused the request (`4xx`) is not stored, so the same key can be used again once the cause is gone, for example when the device was offline. With the header, both can answer `idempotency_key_invalid`, `idempotency_in_progress`, `idempotency_mismatch`, `idempotency_outcome_unknown` and `idempotency_unavailable`; their pages under Error codes now cover the two operations and say what to read when the outcome is unknown. The messages of `idempotency_in_progress` and `idempotency_outcome_unknown` now say "check the order or subscription", on the refund and the cancellation too. Without the header the endpoints behave exactly as before. The sandbox has the change since platform release 2026.11.2.2782; production gets it with the platform's next release, and this entry says when. Until then production ignores the header on these two endpoints.