Sandbox: real offers, real PNRs, no tickets
In the sandbox these endpoints work against real carrier test inventory: a search returns real offers and you can create a real booking with a carrier PNR. Two things are worth knowing before you build against them.
- Sandbox orders are test reservations. Nobody flies on them, and they raise no fee. Cancel what you create; anything left over expires on its own payment time limit.
- Sandbox orders are never ticketed. A paid order comes back
confirmedwith an emptytickets[]and a warning saying why. Readstatusandtickets[], not the HTTP code — that is the check production relies on too.
Orders
Change order
Apply an OrderChange — reissue, add ancillaries, cancel segments, complete payment.
PUT
/v1/orders/{orderID}Requires X-API-KeyThe raw
|---|---|
|
|
|
|
|
OrderChange passthrough. action selects what the airline is asked to do:| Action | Meaning ||---|---|
|
ticketing | issue tickets against a confirmed order ||
ancillaries | add bags / seats / meals ||
reissue | change flights — penalty and fare difference usually apply ||
cancel_segments | cancel some but not all flights ||
complete_payment | pay an outstanding amount on a held order |> **reissue and cancel_segments accept an OFFER.** Name the reshop or cancel offer you are accepting in offer_ids (segment_ids is still read as offers when offer_ids is empty, for older callers). With an add-collect, add a payment block for the reshop offer's total_amount so the difference is paid in the same call — an unpaid add-collect is a change the carrier will not make. POST /v1/orders/{orderID}/change/confirm does the same with a clearer body.> Extras have their own routes now. POST /v1/orders/{orderID}/services and POST /v1/orders/{orderID}/seats price every extra from the catalogue this API served for the order and refuse one it never showed; this raw passthrough sends what you give it. Paid seat assignment on an existing order is still not available on every carrier — the airline's page says whether it is.?airline= is now optional: the airline comes from your stored order (not the order ID), and a value that disagrees with it is refused with 400 airline does not match the order. It exists only for callers that still send it out of habit.Request example
curl --request PUT \
--url https://api.norba.io/v1/orders/{orderID} \
--header "X-API-Key: $NORBA_KEY" \
--header "Content-Type: application/json" \
--data '{ "action": "ticketing", "payment": { "method": "CARD", "currency": "EUR", "amount": 380.62 } }'Response example
Response example
{
"order_id": "AA001Y1XD7ZA6",
"pnr": "JBQGEY",
"status": "ticketed",
"total_amount": 380.62,
"tickets": [
{
"ticket_number": "001-1234567890",
"passenger_id": "PAX96101",
"status": "issued"
}
]
}Path parameters
orderIDstringRequiredCanonical order ID.
Example:
AA001Y1XD7ZA6Query parameters
airlinestringIATA code. Optional — inferred from your stored order. A value that disagrees with the persisted carrier is refused with
400 airline does not match the order.Example:
AARequest body
actionstringRequiredticketing, ancillaries, reissue, cancel_segments or complete_payment.segment_idsarray<string>Segments the action applies to (
cancel_segments).offer_idsarray<string>The reshop or cancel offers being accepted (
reissue, cancel_segments).ancillariesarray<Ancillary>Ancillaries to add. Prefer
POST /v1/orders/{orderID}/services, which prices them for you.seatsarray<Seat>Seats to assign. Prefer
POST /v1/orders/{orderID}/seats, which prices them for you.paymentobjectPayment to authorise:
method, currency, amount, card.Error codes
400invalid json, or airline does not match the order when a supplied ?airline= disagrees with the persisted carrier.502The airline rejected the change.
503coming_soon — order writes disabled in this environment.