> For the complete documentation index, see [llms.txt](https://resources.atriptech.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://resources.atriptech.com/api-document/readme/booking-overview/create-order.md).

# Create Order

{% hint style="info" %}
💬 **Need help?** If you're stuck, ask Eva on ATRIP for instant diagnostics.

<a href="https://www.atriptech.com/" class="button primary" data-icon="comments">Ask Eva</a>
{% endhint %}

Use this page to place the booking after verification.

{% hint style="info" %}
Before calling `order.do`, read `bookingRequirement` from the verify response.

Use it to decide which passenger and document fields are required for this booking.
{% endhint %}

Start here when you need to:

* create the booking after verify
* build the request from `sessionId` and `bookingRequirement`
* capture the `orderNo` for payment and follow-up

### FAQ

#### What do I need before `order.do`?

You need a fresh `sessionId` from verify, the current `bookingRequirement`, passenger details, contact details, and ancillary selections when required.

Use the `sessionId` within 2 hours after `verify.do`.

If seat selection is included, decide the seat fulfillment handling mode before `order.do`.

#### What should I keep after `order.do`?

Keep the returned `orderNo`.

Use it for payment, order query, and later follow-up.

### Main API

* `order.do`

### Inputs

* `sessionId` from verify, valid for up to 2 hours
* `bookingRequirement` from verify
* Passenger details
* Contact details
* Ancillary selections when needed
* Seat fulfillment handling mode when seat selection is included

### Key outputs

* `orderNo`
* Initial booking status
* Airline and pricing details tied to the order

### Common build rules

Use `bookingRequirement` to decide which passenger and document fields are mandatory.

Keep ancillary mapping consistent with the current verify response.

Do not use a `sessionId` older than 2 hours.

Do not build the order from stale verify data.

If seat selection is included, pass the seat fulfillment handling mode in the order request.

Use the same order request to define how Atlas should handle seat fulfillment failure.

Supported modes:

* `STOP_TICKET` — stop ticket issuance, cancel the whole order, and refund it
* `STOP_SEAT` — issue the ticket, remove the seat, and refund the seat amount
* `SIMILAR_SEAT` — issue the ticket with a similar seat selected by operations

For deposit customers, `STOP_SEAT` may require a split fund order and a `credit note`.

### Use this when you need

* Standard order creation
* FR order creation before commit
* Booking with ancillaries

### What comes next?

#### Standard payment path

Continue to [Payment & Ticketing](/api-document/readme/booking-overview/payment-and-ticketing.md) with `orderNo`.

#### FR flow

If the airline is FR, complete [Confirm Order](/api-document/readme/booking-overview/confirm-order.md) before payment.

### Related pages

* [Verify](/api-document/readme/booking-overview/verify.md)
* [Payment & Ticketing](/api-document/readme/booking-overview/payment-and-ticketing.md)
* [Booking APIs](/api-document/api-reference/booking-apis.md)

### Full API reference

See endpoint-level details here:

* [Create Order](/api-document/api-reference/booking-apis/create-order.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://resources.atriptech.com/api-document/readme/booking-overview/create-order.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.