The OTA Channel Manager API issues tickets and coupons on behalf of an external sales channel from a
single order submission. createOrder and replaceOrder are asynchronous: they accept the order,
return immediately with status = Submitted, and issuance is performed in the background. Partners
then learn the outcome either by subscribing to the
ota_cm_order_processed webhook or by polling getOrder.
The walk-through below covers the recommended async flow end-to-end.
Before submitting your first order, decide how your integration learns that an order has settled. Pick one of:
Webhook (recommended). Subscribe to ota_cm_order_processed. The event fires once per
order, when the order has reached a terminal state (Issued, Draft, or Error).
The payload carries the orderId, the OTA Channel Manager’s buyFromOrderReference, and
the final status — enough to look the order up, reconcile it on your side, and decide on
a follow-up action. The webhook also acts as a heartbeat: if you never see an event for an
order you submitted, the order has not finished processing.
Polling. Call getOrder periodically until status is one of Issued, Draft, or
Error. This works for environments where exposing an inbound HTTPS endpoint is hard, but
consumes API quota and adds latency. Orders are picked up for processing on roughly a
60-second cadence, so an order can sit as Submitted for up to a minute before it starts
moving; once it does, settling to a terminal state typically takes a few seconds. A
polling cadence of 10–15 seconds is reasonable — faster than that adds load without buying
you anything.
You do not need to pick before each order — pick once for the integration.
Send the full order in a single call. The combination of partnerId and sellToOrderReference
must be unique per partner. Include paymentReference if payment has already been captured;
omit it if you intend to confirm payment in a second step (see step 4).
The response carries status = Submitted, the assigned orderId, and the OTA Channel
Manager’s buyFromOrderReference. Items, wallets, and the manifest are empty — they will
be populated once issuance settles. Capture the orderId; every subsequent call uses it.
How you wait depends on the choice in step 1.
Webhook subscribers receive ota_cm_order_processed from your registered endpoint when
the order reaches a terminal state. The payload is small by design — it carries orderId,
buyFromOrderReference, and status. Call getOrder to fetch the full representation
(wallets, ticket and coupon assets, prices, manifest URLs):
Pollers call the same endpoint at their chosen cadence and inspect status:
In both flows, the final response looks like this:
If you did not include paymentReference in createOrder, the order settles in Draft.
Tickets and coupons have been minted but are not valid until confirmed. Send the reference
with confirmOrder to move the order to Issued and make the assets valid:
confirmOrder is synchronous and idempotent — confirming an already-Issued order is a
no-op.
Use replaceOrder to retry a failed order or to change a draft. partnerId and
sellToOrderReference are immutable under PUT; all other header fields, plus the entire
items array, are replaced. Any previously issued wallets, tickets, and coupons are
destroyed and the order is re-submitted through the same async pipeline.
Replacement is only allowed when the existing order is Draft or Error.
The response carries status = Submitted again — wait for the next webhook (or poll) to see
the new terminal state.
DELETE /channelManager/:orderId tears down the order’s wallets, tickets, and coupons. The
order row survives as Cancelled if it was previously Issued or Cancelled; it is
removed outright if it was Draft or Error. Orders that are still in-flight
(Submitted, Scheduled, Processing) cannot be cancelled — wait for them to settle.
Use listOrdersByPartner to fetch orders for one partner, optionally filtered by status,
sellToOrderReference, or a receivedAt window. The returned objects are compact
summaries; follow up with getOrder to inspect items and wallets. Filtering on
status=Submitted,Scheduled,Processing is a quick way to see what is still in-flight.