> 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/get-offer.md).

# Get Offer

{% 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 when you need an independent offer lookup flow.

{% hint style="info" %}
Use OpenAPI naming as the source of truth.

Use `getOffers.do` in docs and integration.
{% endhint %}

Start here when you need to:

* price a known itinerary without the standard search flow
* fetch a fresh `OfferId` before order creation
* run baggage or seat lookup before booking

### FAQ

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

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

This flow is a good fit when shopping happens outside Atlas and Atlas is used as the booking and pricing layer.

#### What should I keep from the Get Offer response?

Keep `OfferId`.

Use it as the key identifier for downstream order creation.

Use the same `OfferId` for `seatAvailability.do` when seat lookup is needed before booking.

### Main API

* `getOffers.do`

### Inputs

* Accurate itinerary details
* Passenger mix when required by the request
* Any fields required by the current API reference

### Key outputs

* Latest bookable fare
* Inventory status
* `OfferId` for downstream order creation
* `OfferId` for `seatAvailability.do` in the Get Offer path

### What comes next?

#### Minimal path

Continue with [Create Order](/api-document/readme/booking-overview/create-order.md), then [Payment & Ticketing](/api-document/readme/booking-overview/payment-and-ticketing.md).

#### Path with seats and baggage

Use [Seats](/api-document/readme/booking-overview/seats-and-baggage.md) and [Baggage](/api-document/readme/booking-overview/baggage.md) before order creation.

### How this differs from standard search

#### Standard search flow

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

That flow is best when you want Atlas to return available offers first.

#### Get Offer flow

Use `getOffers.do` when you already know the target itinerary.

This flow is better for direct price checks, independent validation, and external shopping paths.

#### Practical difference

The standard search flow usually continues through `verify.do`.

The Get Offer flow is designed around the returned `OfferId` for downstream order creation.

### Use this when you need

* An offer lookup flow without standard search
* A secondary price check before order creation
* Lowest-price validation before ticketing
* A flow driven by your own flight data source

### Common scenarios

#### Use your own flight data source

Use `getOffers.do` when flight selection happens outside the standard Atlas search flow.

This lets you fetch the latest bookable fare and `OfferId` directly.

#### Run a final price check before order creation

Use `getOffers.do` to re-check the latest bookable price before you create the order.

This helps reduce fare drift between quote and booking.

#### Compare channels before ticketing

Use `getOffers.do` when you need a real-time validation point before sending the order into ticketing.

This is useful when you optimize for the latest available price before completion.

### Recommended business chain

#### Minimal chain

Use this path when you only need fare retrieval and ticketing:

1. Call `getOffers.do`
2. Keep the returned `OfferId`
3. Call `order.do`
4. Call `pay.do`

#### Chain with seats and baggage

Use this path when baggage and seat upsell are part of the booking flow:

1. Call `getOffers.do`
2. Confirm the fare and target flight
3. Query `getLuggage.do` or `seatAvailability.do` if needed
4. Create the order with `order.do`
5. Complete payment with `pay.do`

#### When to stop and re-check

Stop and refresh the offer if any of these change:

* target flight
* passenger mix
* expected fare
* ancillary requirement that changes the booking plan

### Best practice

Refresh the offer when booking-critical input changed or when booking was delayed.

Do not build the order from stale offer assumptions.

### Typical flow

{% stepper %}
{% step %}

### Get Offer

Call `getOffers.do` with the target itinerary.

Keep the returned `OfferId`.
{% endstep %}

{% step %}

### Seats and baggage

Query `getLuggage.do` or `seatAvailability.do`.

Run this after the offer matches your target flight and price.

For seat lookup, pass the returned `OfferId`.
{% endstep %}

{% step %}

### Create Order

Call `order.do` with the returned `OfferId` and required booking data.
{% endstep %}

{% step %}

### Pay and ticket

Call `pay.do` to complete ticketing.
{% endstep %}
{% endstepper %}

### When to use ancillary queries

#### Use `getLuggage.do`

Use it to surface baggage price and baggage options before booking.

Run it after you confirm the target offer.

#### Use `seatAvailability.do`

Use it to surface seat availability and paid seat selection before booking.

Use the returned `OfferId` as the request context in this flow.

Do not call it with flight data alone.

#### Treat ancillaries as recommended

Include ancillary queries when your booking product supports seat and baggage upsell.

The shortest technical path is still `getOffers.do` → `order.do` → `pay.do`.

### Implementation guidance

#### Best fit

This flow fits partners who already control shopping logic.

It also fits flows where a final Atlas-side price check is needed before booking.

#### Data to retain

Retain the exact itinerary context used for `getOffers.do`.

Retain the returned `OfferId` until order creation is completed.

#### Suggested validation

Before `order.do`, confirm:

* flight matches the intended itinerary
* fare matches the expected sell logic
* passenger mix is still correct
* ancillary selection is complete when required

### Operational notes

#### Source of truth

Use the OpenAPI schema as the source of truth for request fields and response fields.

#### Naming

Use `getOffers.do` in implementation material, support replies, and customer-facing guidance.

#### Error handling

If the order or payment step fails because fare or availability changed, restart from a fresh offer lookup.

Use the latest returned data instead of retrying with stale assumptions.

### FAQ

#### Does `getOffers.do` replace `search.do`?

No.

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

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

#### Do I still need `verify.do` in this flow?

Not in the standard Get Offer path described on this page.

This flow is centered on `OfferId` and downstream order creation.

#### Is ancillary lookup mandatory?

Seat and baggage lookup is strongly recommended when your product includes ancillary upsell.

Use `getLuggage.do` or `seatAvailability.do` before `order.do` to improve conversion and traveler clarity.

#### When should I refresh the offer?

Refresh the offer when any booking-critical input changes.

Typical triggers:

* passenger count changes
* target flight changes
* expected fare changes
* booking is delayed and current pricing may be stale

#### Can I use Get Offer with my own shopping engine?

Yes.

This is one of the main use cases for this flow.

Keep your itinerary mapping consistent with the request fields defined in OpenAPI.

### Failure handling

#### If `getOffers.do` fails

Check request completeness first.

Then confirm itinerary data, passenger data, and any required fields defined in OpenAPI.

If the issue is transient, retry with controlled backoff.

#### If `order.do` fails after Get Offer

Do not assume the returned offer is still valid.

If the failure points to fare, inventory, or booking-state drift, call `getOffers.do` again and rebuild the order request from fresh data.

#### If `pay.do` fails

Check whether the order was already paid or is still processing.

Do not send duplicate payment blindly.

Query order state when needed before retrying.

#### When not to retry immediately

Avoid instant retries when the issue may be caused by:

* stale fare data
* unsupported payment method
* invalid passenger or contact data
* airline-side restrictions

Fix the root cause first.

### Logging and support guidance

#### Keep these values in logs

Capture the minimum fields needed for troubleshooting:

* request timestamp
* itinerary summary
* passenger mix
* `OfferId`
* `orderNo` after order creation
* payment method type
* final response status and message

#### Keep request linkage clear

Log the Get Offer request and the downstream order request as one business chain.

This makes fare drift and state mismatch easier to trace.

#### Escalation readiness

When escalating, provide:

* API name
* request time
* key identifier such as `OfferId` or `orderNo`
* response code
* response message

This speeds up support review.

### Notes

* This flow does not start from the standard `search.do` path.
* Use the current API reference as the source of truth for required fields.
* Use OpenAPI naming as the source of truth for interface names.
* Use `getOffers.do` as the official interface name in implementation material.

### Related pages

* [Search](/api-document/readme/booking-overview/search.md)
* [Create Order](/api-document/readme/booking-overview/create-order.md)
* [Payment & Ticketing](/api-document/readme/booking-overview/payment-and-ticketing.md)
* [Seats](/api-document/readme/booking-overview/seats-and-baggage.md)
* [Baggage](/api-document/readme/booking-overview/baggage.md)

### Full API reference

See endpoint-level details here:

* [Get Offer](/api-document/api-reference/booking-apis/get-offer.md)
* [Seat](/api-document/api-reference/booking-apis/inflow-seat-and-baggage.md)
* [Baggage](/api-document/api-reference/booking-apis/baggage.md)
* [Create Order](/api-document/api-reference/booking-apis/create-order.md)
* [Payment & Ticketing](/api-document/api-reference/booking-apis/payment-and-ticketing.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/get-offer.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.