Post-Booking Servicing
Servicing is everything that happens to an order once it exists — ticketed or still held. Any order that is not cancelled, refunded or failed can still be serviced. It is the long tail of NDC operations and the most varied across airlines. Norba normalises these operations into a consistent REST interface.
A booking made through Norba is issued on Norba's accreditation — the agency receives no IATA number and no airline login — so it must be changed, cancelled or refunded through these endpoints, never directly with the carrier. A change made outside the API puts the two records out of step, and any airline debit memo it causes is passed on to the agency (Production Agreement §7.5 and §12). Where a carrier insists on dealing with the agency directly, tell Norba first.
Servicing categories
| Category | Trigger | Norba endpoint |
|---|---|---|
| Seat assignment | Passenger wants a specific seat | GET /v1/orders/{id}/seats?segment_id= → POST /v1/orders/{id}/seats (paid on the spot once ticketed). Not every carrier allows a paid seat after booking — the airline's page says; sell it inside POST /v1/orders there |
| Ancillary additions | Bag, meal, lounge or Wi‑Fi | GET /v1/orders/{id}/services → POST /v1/orders/{id}/services. Priced from what the GET showed, never from the client; paid on the spot once ticketed |
| Travel documents | Passport / APIS data | Supplied in the passenger objects of POST /v1/orders — there is no separate SSR endpoint |
| Voluntary change | Passenger wants a different flight | POST /v1/orders/{id}/reshop → POST /v1/orders/{id}/change/confirm with the offer_id and, for an add-collect, a payment block (POST /v1/orders/{id}/change is an optional reprice, not the commit) |
| Involuntary change | Airline rescheduled or cancelled a flight | GET /v1/orders/{id}/history (the airline's own record, where it exposes one) or GET /v1/orders/{id}?refresh=true to detect it → POST /v1/orders/{id}/reshop |
| Reprice | What would a change cost right now? | POST /v1/orders/{id}/quote — a write, and billed as one |
| Cancellation | Stop selling this booking, or part of it | POST /v1/orders/{id}/cancel → POST /v1/orders/{id}/cancel/confirm, or DELETE /v1/orders/{id} for a bare 204. With segment_ids on both calls only those flights are dropped and the order becomes partially_cancelled |
| Refund | How much comes back, then close it | GET /v1/orders/{id}/refund-eligibility → POST /v1/orders/{id}/refund, which reports the amounts the airline quoted at the moment of cancelling |
| History | Who changed what, and when | GET /v1/orders/{id}/history — Norba's timeline merged with the carrier's own audit trail where its connector reads one |
Voluntary change flow
The most common servicing scenario: a passenger wants to change to a different flight.
Cancelling and refunding
POST /v1/orders/{id}/cancel returns the refund and the penalty; POST /v1/orders/{id}/cancel/confirm performs the cancellation, and DELETE /v1/orders/{id} does the same in one call and answers 204. All three are the cancellation for an order that has not been ticketed.
A ticketed order takes the same three calls: the connector asks the airline for its cancel offer and accepts it, which voids the documents, so POST /v1/orders/{id}/cancel quotes what comes back and POST /v1/orders/{id}/cancel/confirm performs it. Sandbox orders are never ticketed, so in the sandbox every order takes the unpaid path.
Part of a trip cancels the same way with segment_ids on both calls. POST /v1/orders/{id}/cancel with segment_ids asks the airline what dropping only those flights would return, and answers with partial: true and a quote_id that is the airline's cancel offer; POST /v1/orders/{id}/cancel/confirm with the same segment_ids and that quote_id as cancellation_quote_id accepts it. The order comes back partially_cancelled, still alive for the flights that remain, and the timeline records segments_cancelled with the segments and the offer.
A refund reads GET /v1/orders/{id}/refund-eligibility first — refund_amount is already net of penalty_amount, and where the airline files the two in different currencies the penalty is not deducted and the gross is reported — and then calls POST /v1/orders/{id}/refund, which asks the airline for the same quote once more, cancels the order where it is still open and marks it refunded, answering with refund_amount, penalty_amount and currency as the carrier stated them at that moment. Norba moves no money: the airline returns the fare to the original form of payment on its own cycle. What Norba charged for the booking is a separate question, answered below.
From the dashboard, and on your behalf
Every operation on this page is also on the Orders page of the dashboard. Open a booking and its Actions menu offers pay & ticket, add extras, choose seats, change flights, refresh from the airline, history, cancel (whole or by flight) and refund; each asks for what it needs — a card, a seat on the map, the new dates — on the same panel as the booking, and reports the result there. The dashboard calls the same handlers the API does, authenticated by your session instead of an API key, so a change made from the browser leaves the same record, raises the same fees and fires the same webhooks as one made from your code.
Norba support can perform the same operations on any booking made through the platform, on your behalf, from the back-office. Every such change is made through the same path as yours, requires a written reason that is recorded in the audit trail, is attributed to the operator, and is announced to you through the order webhooks you already receive; a cancellation or a refund additionally requires the operator to type the order id back. The order's history names support as the actor, so a change you did not make is never mistaken for one you did.
What a servicing call costs
Two charges can arise from the calls on this page: one for the operation, and — when the operation sells something — one on what it sold. Both are Norba's own charges, separate from each other and from what the traveller pays the airline.
- Every servicing write that succeeds — any POST, PUT or DELETE under /v1/orders/{id}/…, the quote steps included: POST /quote, POST /reshop, POST /change and POST /cancel — is a metered call plus the flat €2.00 servicing fee. The reshop → change → change/confirm flow above is three of them, not one. A 4xx or 5xx raises no servicing fee, because nothing happened to the order; the call itself is still metered. Reads (GET /v1/orders/{id}, GET /v1/orders/{id}/history, GET /v1/orders/{id}/refund-eligibility, and the GET catalogues under /services and /seats) raise no servicing fee.
- A sale after the booking is still a sale. A seat, bag or other extra added with POST /v1/orders/{id}/services, POST /v1/orders/{id}/seats, PUT /v1/orders/{id} or POST /v1/orders/{id}/commit, and fare added by a reissue at POST /v1/orders/{id}/change/confirm, carries the same ad-valorem fee it would have carried at booking — computed on the increase between the order's persisted total and the total the carrier confirmed afterwards. The flat servicing fee is charged as well, not instead: one is for the operation, the other for what it sold. A decrease — a partial cancellation, a refund — is never billed this way.
- An order cancelled or refunded within 24 hours of booking has its Norba fees credited back automatically, once, whichever of the cancel or refund paths you use. Outside that window the fees already charged stay due, and the cancellation or refund carries its own flat fee.
- Sandbox orders raise neither fee. The calls are still metered.
Rates, the basis each fee is computed from and how the credit appears on an invoice are in Billing & Payments. What the traveller pays the airline, and how a change is settled with the carrier, is in Payment Flow.
Ancillary types
Norba normalises airline ancillaries into a consistent catalogue. Each ancillary has a type, a service code (RFIC/RFISC from ATPCO), pricing, and availability constraints. Seats and ancillaries sent on POST /v1/orders/{id}/services, POST /v1/orders/{id}/seats, PUT /v1/orders/{id} or POST /v1/orders/{id}/commit are bounds-checked exactly as they are at booking: too many entries, or an over-long reference, is a 400 before the airline is called; and on the two dedicated routes an extra the order's own catalogue never showed is a 422 rather than a purchase at the client's number.
| Type | Examples |
|---|---|
| Checked bag | First checked bag (23 kg), second checked bag, overweight bag. |
| Carry-on bag | Cabin bag beyond the basic allowance. |
| Seat selection | Standard seat, extra legroom, exit row, window/aisle preference. |
| Meal | Hot meal, vegetarian, kosher, halal, child meal. |
| Lounge access | Airline lounge, contract lounge, arrival lounge. |
| Priority boarding | Zone 1–2 boarding ahead of general boarding. |
| Fast track | Expedited security lane at departure airport. |
| Wi‑Fi | In-flight internet access — messaging pass or full streaming. |
| Sports equipment | Golf clubs, skis, surfboard, bicycle. |
| Pet in cabin / hold | Small pet in cabin or larger pet in temperature-controlled hold. |
| Upgrade | Upgrade to premium economy, business, or first class (space-available). |
| Insurance | Travel insurance bundled with the booking. |
Special Service Requests (SSRs)
SSRs are three-letter codes airlines use to handle special passenger needs. There is no /ssrs route. APIS data (passport number, nationality, issuing country, expiry) is supplied in the document object of each passenger on POST /v1/orders. Assistance SSRs are asked for as offers: GET /v1/offers/{offerID}/services?ssr=WCHR,UMNR (or, on an existing booking, GET /v1/orders/{orderID}/services?ssr=…) asks the airline for offers on the named codes, and what comes back is sold like any other ancillary — inside POST /v1/orders, or afterwards with POST /v1/orders/{orderID}/services. An airline whose connector does not support the qualifier answers 501 rather than dropping the request silently. Meal and pet codes take the same path where the carrier files them as services. The AA sandbox currently returns no SSR offers; that is an AA-side gap, not a refusal.
| Code | Meaning |
|---|---|
| WCHR | Wheelchair — passenger can walk to seat but needs wheelchair for distance. |
| WCHS | Wheelchair — passenger cannot walk up steps but can walk to seat. |
| WCHC | Wheelchair — passenger completely immobile, needs carry-on/off. |
| VGML | Vegetarian meal (lacto-ovo). |
| KSML | Kosher meal. |
| MOML | Muslim meal (halal). |
| UMNR | Unaccompanied minor. |
| DOCS | Passport/visa data (APIS). |
| DEAF | Deaf passenger. |
| BLND | Blind passenger. |
| PETC | Pet in cabin. |