Create a new OTA Channel Manager order.
The combination of partnerId and sellToOrderReference must be unique; resubmitting the same
pair returns 400 Bad Request. Each items entry must reference an existing item — a package
item expands into multiple component admissions (and, where configured, coupons), while a
non-package item is a single ticket.
The endpoint is asynchronous: it accepts the order, persists it with
status = Submitted, and returns immediately. The order is then processed in the background,
transitioning through Scheduled → Processing → Issued | Draft | Error. Subscribe to the
ota_cm_order_processed webhook to be notified when the order reaches a terminal state, or poll
getOrder until status is one of Issued, Draft, or Error.
Your Entra Tenant ID. More details.
Your Business Central Environment. More details.
Your Business Central Company. More details.
Used for API versioning. More details.
Globally unique identifier of the OTA Channel Manager partner that originated the order. The partner must exist and be active in the OTA Channel Manager Partner Setup; otherwise the order is rejected.
The partner’s own reference for the order. Unique per partner; combined with partnerId it identifies the order end-to-end. Maximum 50 characters.
Email address of the customer the order is sold to. Stored on the order and on each issued wallet for the partner’s own use; the OTA Channel Manager does not send anything to this address. Maximum 100 characters. Can be overridden per item.
Language code (uppercased) for the customer the order is sold to. Used to localize the description fields on items and assets via Item Translation. Must be a valid Business Central language code. Maximum 10 characters. Can be overridden per item.
Reference to the partner-side payment transaction. May be supplied at order creation, or later via confirmOrder. Required to move an order from Draft to Issued. Maximum 50 characters.
Lifecycle state of an OTA Channel Manager order. The terminal states are Issued, Draft, Cancelled,
and Error. The non-terminal states (Submitted, Scheduled, Processing) belong to the asynchronous
issuance pipeline:
Submitted — async order is queued for background processing.Scheduled — order has been picked up for processing.Processing — ticket and coupon issuance is running.Draft — assets are issued but no paymentReference was supplied. Call confirmOrder to release the
order to Issued.Issued — all assets have been issued, coupons have been posted, and the wallet manifest is
available at manifestUrl.Cancelled — order has been cancelled. Wallets are destroyed but the order row is retained for
audit.Error — issuance failed. Inspect statusMessage for details. The order can be replaced
(replaceOrder) to retry, or deleted (deleteOrder) to remove it.Human-readable detail about the current status, set by the OTA Channel Manager. Populated for Error; empty otherwise.
Globally unique identifier of the OTA Channel Manager partner that originated the order. The partner must exist and be active in the OTA Channel Manager Partner Setup; otherwise the order is rejected.
The partner’s own reference for the order. Unique per partner; combined with partnerId it identifies the order end-to-end. Maximum 50 characters.
The OTA Channel Manager’s own document number for the order, used as a stable identifier for partner-side reconciliation. Maximum 20 characters.
Email address of the customer the order is sold to. Stored on the order and on each issued wallet for the partner’s own use; the OTA Channel Manager does not send anything to this address. Maximum 100 characters. Can be overridden per item.
Language code (uppercased) for the customer the order is sold to. Used to localize the description fields on items and assets via Item Translation. Must be a valid Business Central language code. Maximum 10 characters. Can be overridden per item.
Reference to the partner-side payment transaction. May be supplied at order creation, or later via confirmOrder. Required to move an order from Draft to Issued. Maximum 50 characters.
When true (or 1), opt out of async processing and run ticket issuance synchronously inside the
request. The response then carries the final order state (Issued, Draft, or Error) instead of
Submitted.
Default behavior — and the recommended mode — is asynchronous. In async mode the order is processed
in the background; subscribe to the ota_cm_order_processed webhook for completion notifications,
or poll getOrder until the status reaches a terminal value.