> 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.md).

# Booking Overview

{% 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 section for the end-to-end booking flow.

<figure><img src="/files/DqGxAvaOLqUya9iuYXgU" alt=""><figcaption><p>Booking flow from search to payment and follow-up</p></figcaption></figure>

Start here when you need to:

* understand the standard Atlas API booking flow
* choose between `search.do` and `getOffers.do`
* see which identifier to keep at each step
* evaluate route coverage and raw prices in pre-sale

### FAQ

#### What is the standard Atlas API booking flow?

The standard flow is `search.do` → `verify.do` → `order.do` → `pay.do` → `queryOrderDetails.do`.

If the airline is FR, add `orderCommit.do` before payment.

#### When should I use `getOffers.do` instead of `search.do`?

Use `search.do` when Atlas is your main shopping entry point.

Use `getOffers.do` when you already know the target itinerary or need an independent price check.

#### When should I use `priceCompareSearch.do`?

Use `priceCompareSearch.do` for pre-sale route coverage checks and raw price discovery.

It is not part of the standard booking flow.

Do not treat it as a production booking price source.

### Pages in this section

* [Search](/api-document/readme/booking-overview/search.md)
* [Price Compare Search](/api-document/api-reference/booking-apis/price-compare-search.md)
* [Get Offer](/api-document/readme/booking-overview/get-offer.md)
* [Verify](/api-document/readme/booking-overview/verify.md)
* [Create Order](/api-document/readme/booking-overview/create-order.md)
* [Confirm Order](/api-document/readme/booking-overview/confirm-order.md)
* [Payment & Ticketing](/api-document/readme/booking-overview/payment-and-ticketing.md)
* [Query Order](/api-document/readme/booking-overview/query-order.md)
* [Seats](/api-document/readme/booking-overview/seats-and-baggage.md)
* [Baggage](/api-document/readme/booking-overview/baggage.md)

### Key identifiers in the booking flow

Keep and reuse the right identifier at each stage:

* `routingIdentifier` from `search.do`
* `sessionId` from `verify.do`
* `orderNo` from `order.do`
* airline PNR and `ticketNos` from `queryOrderDetails.do` after ticketing

For the Get Offer path, keep `OfferId` from `getOffers.do`.

For seat queries, keep `sessionId` from `verify.do` or `OfferId` from `getOffers.do`.

### What this section covers

* Search for flight offers
* Retrieve offers through an independent Get Offer flow
* Verify fares and routing
* Create orders
* Confirm FR orders when required
* Pay and issue tickets
* Retrieve booking details
* Run advanced search flows
* Query seats
* Query baggage

### Which flow should you choose?

#### Standard search flow

Use this when Atlas is your main shopping and booking layer.

This path uses `search.do` first, then `verify.do` before booking.

#### Get Offer flow

Use this when the itinerary is already known or when you need an independent price check before order creation.

This path starts with `getOffers.do` and uses `OfferId`.

#### Price compare search

Use this when you need pre-sale coverage visibility and raw price signals.

This path uses `priceCompareSearch.do`.

It does not replace the standard booking flow.

### Typical flow

{% stepper %}
{% step %}

### Standard search path

Search for available offers and keep the returned identifiers.
{% endstep %}

{% step %}

### Verify

Recheck fare, routing, and booking requirements before order creation.
{% endstep %}

{% step %}

### Order

Create the booking with passenger, contact, and ancillary details.
{% endstep %}

{% step %}

### Optional FR confirmation

Most airlines skip this step.

If the airline is FR, call `orderCommit.do` and wait for user confirmation before payment.
{% endstep %}

{% step %}

### Pay

Complete payment and wait for ticketing to finish.
{% endstep %}
{% endstepper %}

#### How to include seats and baggage

Recommend `getLuggage.do` and `seatAvailability.do` in the booking flow when the product supports ancillary upsell.

Use them before payment to improve traveler clarity and order conversion.

Call `seatAvailability.do` only with a valid `sessionId` or `OfferId`.

Do not call it from flight data alone.

### Alternate flow

Use this path when you already know the target itinerary or need an independent price check.

{% stepper %}
{% step %}

### Get Offer

Call `getOffers.do` and keep the returned `OfferId`.
{% endstep %}

{% step %}

### Seats and baggage

Query `getLuggage.do` and `seatAvailability.do` before booking when ancillary upsell is part of the product.

Use the returned `OfferId` for `seatAvailability.do` when seat lookup is needed in this flow.
{% endstep %}

{% step %}

### Order

Create the booking with `order.do`.
{% endstep %}

{% step %}

### Pay

Complete payment with `pay.do`.
{% endstep %}
{% endstepper %}

#### What happens after `pay.do`?

Do not assume payment and final ticketing happen at the same moment.

Use `queryOrderDetails.do` until the order reaches the final ticketed state.

Webhook can help, but it should not be your only confirmation path.

### Main APIs

* `search.do`
* `priceCompareSearch.do`
* `getOffers.do`
* `verify.do`
* `order.do`
* `orderCommit.do`
* `pay.do`
* `queryOrderDetails.do`
* `smartSearch.do`
* `seatAvailability.do`
* `getLuggage.do`

### Recommended next pages by task

#### Build the standard flow

Use:

* [Search](/api-document/readme/booking-overview/search.md)
* [Verify](/api-document/readme/booking-overview/verify.md)
* [Create Order](/api-document/readme/booking-overview/create-order.md)

#### Build payment and follow-up

Use:

* [Payment & Ticketing](/api-document/readme/booking-overview/payment-and-ticketing.md)
* [Query Order](/api-document/readme/booking-overview/query-order.md)

#### Build the alternate offer path

Use:

* [Get Offer](/api-document/readme/booking-overview/get-offer.md)
* [Seats](/api-document/readme/booking-overview/seats-and-baggage.md)
* [Baggage](/api-document/readme/booking-overview/baggage.md)

#### Evaluate pre-sale route coverage

Use:

* [Price Compare Search](/api-document/api-reference/booking-apis/price-compare-search.md)
* [Search](/api-document/readme/booking-overview/search.md)

### Use this when you need

* A standard search-to-ticket flow
* An independent offer lookup and price-check flow
* A pre-sale route coverage and raw-price check
* FR order confirmation support when applicable
* Seat and baggage upsell
* Real-time or smart search options

### Full API reference

Use endpoint-level details here:

[Booking APIs](/api-document/api-reference/booking-apis.md)

### Related pages

* [Quick Start](/api-document/readme/quick-start.md)
* [Get Sandbox Credentials](/api-document/readme/quick-start/making-requests.md)
* [Error Codes](/api-document/troubleshooting-and-support/errors-handing.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.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.