Orders
Scope: orders:read.
GET /api/v1/orders
Section titled “GET /api/v1/orders”Parameters: offset, limit, family, status, client_reference (exact match).
An unknown value of family or status is read as “no filter”. The order is fixed and cannot be
configured: newest first.
| Field | Meaning |
|---|---|
product, kind, family | what was bought; kind: resident or ipv4 |
quantity | number of units bought: addresses for ipv4; for a traffic order always 1 - one package was bought, and the volume is in packages[].traffic.purchased_gb |
price_per_proxy, total | unit price (total / quantity) and order amount; equal for a traffic order |
status | see below |
applied_to_package_id | not empty - the order was applied to an existing package: a traffic top-up or an address renewal |
client_reference | your label from the purchase body |
packages | the traffic package the order issued. Empty for a top-up and for fixed address orders - read their packages via GET /api/v1/packages?family=dedicated, the card has order_id |
GET /api/v1/orders/{id}
Section titled “GET /api/v1/orders/{id}”Same shape as in the list. An order of another account answers 404 without a code key.
Issuance statuses
Section titled “Issuance statuses”A purchase completes within the request, so in the POST /api/v1/packages response the order is
already completed. The other statuses show up when reading orders.
| Status | What to do |
|---|---|
pending, provisioning | poll every 5-10 seconds |
completed | done: the traffic package is in packages[0], the address package is in package_id of the purchase response |
failed | money not charged or returned, you can retry |
refunded | money returned by a support decision; retry as a new purchase |
needs_attention | money charged, handled manually. Do not buy again, contact support |
Instead of polling orders you can read the event log.