Place an order
The money moves synchronously and the profiles do not. By the time you hold the 202, your balance has been debited, the statement row exists and the child orders have been created; provisioning then runs detached and you poll for it.
It answers 202 rather than waiting because one provisioning run can take up to 92 seconds, a quantity-N order drives its units one at a time, and a typical HTTP client gives up at 30 seconds and retries. A retry on a purchase is a double charge. Asynchronous is not a design flourish here; it is the only shape that is safe.
Idempotency-Key is required. There is no way to place an order without one.
Headers
| Name | Type | Rules |
|---|---|---|
| Idempotency-Key * | string | Unique to this order — a UUID, or your own booking id. Send the SAME value if you retry. Scoped per partner and spanning both modes.16–255 characters after trimming |
Body
| Name | Type | Rules |
|---|---|---|
| plan_id * | string | Must begin pl_.≤ 64 characters |
| quantity | integer | How many profiles. Each is provisioned individually.1–50Default 1 |
| reference | string | Your own identifier. Never parsed by us, echoed on every read, and exact-match filterable on the order list. Trimmed; empty becomes null.≤ 255 characters |
| metadata | object | Your own blob, echoed back verbatim — its inner keys are NOT converted to snake_case like the rest of the response. Must be a JSON object; an array or a bare string is a 400.serialises to ≤ 4096 bytes of UTF-8 |
Example
X-Request-Id— Quote it to support. Present on every response, including 401s.
Idempotency-Replayed—true. Set on replays only.