/api/v1/orders/:order_id tenant key Fetches a single order by id (scoped to your account). Poll this for status + tracking after committing — your quotes, commits and cancellations do NOT appear in the activity log, so this is the way to follow an order (what happens to the parcel afterwards does: tracking changes as order.tracking_*, and a package the carrier sends back to us as card.returned / order.returned). The path takes the integer order_id or the order’s reference (101326AA0042, or an older KPTX4821). Requires a real Order ID; set yours in the sidebar and press Run.
RETURNED is terminal, like COMPLETED: the order was fulfilled and shipped, the carrier could not deliver it and brought it back, and the warehouse has scanned its cards back into your inventory. Those cards are yours again — OFFCHAIN, under the same sub-account, in GET /inventory’s default view, and re-delivered with a new position by a GET /cards ?since= sweep. To ship them again, quote and commit a new order with a corrected address: there is no re-ship call, and a RETURNED order does not block a new quote the way a committed or fulfilled one does. A card recorded as missing from the package stays REDEEMED. The order is invoiced like a COMPLETED one — it was fulfilled and shipped, and the return does not undo that.
GET /api/v1/orders/0 These inputs are shared across all docs pages, so an id entered here carries over.
Not run yet. Press Run to make a live call against https://service.rip.fun (through this demo's server-side proxy; the API key never reaches the browser).
curl -X GET 'https://service.rip.fun/api/v1/orders/0' \ -H 'X-API-Key: rip_…'
data)| Field | Description |
|---|---|
order_id / status | Order id + lifecycle status: PENDING_PAYMENT | PENDING | COMPLETED | CANCELLED | RETURNED (see List orders) |
reference | The order’s human-readable number — 101326AA0042: its ship-by day as MMDDYY, then the shared sequence — the one printed on the parcel and read out by the warehouse. null until the order is committed |
unique_ids | Cards on the order |
shipping_total_cents / sales_tax_cents / currency | Pass-through shipping billed (the quoted amount) + tax + currency |
carrier / carrier_service / shippo_rate_id | Committed carrier, service, and quoted rate id |
shippo_tracking_number / shippo_tracking_url / shippo_label_url | Populated once the warehouse buys the label + ships |
previous_tracking_numbers | Tracking numbers of replaced labels, oldest first; [] unless the order was re-labelled |
tracking_status / tracking_status_at | Latest carrier status of the current label and its carrier timestamp; null until first checked. A carrier RETURNED is the parcel on its way back to us, not the order’s status — see returned_at |
returned_at | When the warehouse started processing this order as a returned package — the moment the first card in it was scanned back into your inventory (or recorded as missing from it) — and the order’s status became RETURNED. null on every other status. A parcel can read tracking_status RETURNED for days while it travels back to us; the order stays COMPLETED until the warehouse opens it |
return | null until returned_at is set, then { carrier_reason, started_at, completed_at, cards[] }. carrier_reason is the carrier’s own wording for why the parcel came back ("NO SUCH NUMBER", "REFUSED", …) or null when it gave none; started_at equals returned_at; completed_at is when every card on the order had been accounted for, null while the warehouse is still working through the package; cards[] has one { unique_id, outcome, at } per card handled so far — outcome "reinstated" means the card was in the package and is OFFCHAIN again in your inventory, "missing" means the order listed it but it was not in the package, so it stays REDEEMED. A missing card that turns up later is reinstated and its row flips to "reinstated". The same facts arrive in the activity log as card.returned (per card) and order.returned (once completed_at is set) |
tracking_events | GET /orders/:order_id only. The parcel’s history, oldest first: {type:"label_replaced", occurred_at, previous_tracking_number, tracking_number} when we re-labelled it, and {type:"carrier_scan", occurred_at, tracking_number, status, substatus, details, location} for each carrier scan |
ship_by_at / label_purchased_at / created_at / updated_at | Lifecycle timestamps |
| Status | Code | When |
|---|---|---|
| 400 | invalid order_id | order_id is neither a positive integer nor a reference like 101326AA0042 |
| 404 | order not found | order not part of your account |
See Errors for the response envelope and the full code list.