> 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/support-and-reference/troubleshooting-and-support/errors-handing/202-vs-301-vs-308.md).

# 202 vs 301 vs 308

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

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

Use this page when booking fails and you need to know whether to refresh `search.do`, refresh `verify.do`, or restart the booking flow.

### Short answer

`202` means the `routingIdentifier` expired.

`301` means the `sessionId` expired.

`308` means the price changed before order creation.

They do not have the same recovery path.

### FAQ

#### What does `202` mean?

It means the `routingIdentifier` from `search.do` is no longer valid.

Run `search.do` again.

#### What does `301` mean?

It means the `sessionId` from `verify.do` is no longer valid.

Run `verify.do` again if the search context is still usable.

#### What does `308` mean?

It means the booking price changed between verification and order creation.

Do not resubmit the same order blindly.

Refresh the booking context first.

### Core difference

#### `202` — expired `routingIdentifier`

**Failed stage**

`verify.do`

**What expired**

`routingIdentifier`

**Typical reason**

More than 6 hours passed after `search.do`.

**Next action**

Run `search.do` again.

Then continue to `verify.do` with the fresh `routingIdentifier`.

#### `301` — expired `sessionId`

**Failed stage**

`order.do`

**What expired**

`sessionId`

**Typical reason**

More than 2 hours passed after `verify.do`.

**Next action**

Run `verify.do` again.

Then continue to `order.do` with the fresh `sessionId`.

#### `308` — price changed

**Failed stage**

`order.do`

**What changed**

The current price or fare context

**Typical reason**

Inventory or fare changed after verification.

**Next action**

Refresh the booking context before creating the order again.

In most cases, restart from `search.do` and continue through `verify.do`.

### Quick decision rule

Use this rule in production:

* `202` — refresh search
* `301` — refresh verify
* `308` — refresh booking context and rebuild the order

### How much of the flow must you restart?

#### For `202`

Restart from `search.do`.

The old `routingIdentifier` cannot be reused.

#### For `301`

Restart from `verify.do`.

If the original search context is still valid, you do not need a new search first.

#### For `308`

Treat the previous booking context as stale.

If you are in the standard search flow, restart from `search.do`.

If you are in a Get Offer flow, refresh the offer first.

### Common mistakes

#### Retrying `verify.do` after `202` with the same `routingIdentifier`

Do not do this.

The identifier already expired.

#### Retrying `order.do` after `301` with the same `sessionId`

Do not do this.

The session already expired.

#### Retrying `order.do` after `308` without rebuilding the order

Do not do this.

Price drift usually means the old booking assumptions are stale.

### Best practice

Store these values together:

* identifier type
* identifier creation time
* itinerary summary
* passenger mix
* flow type

This makes the next recovery step obvious.

### Related pages

* [Error Codes](/api-document/support-and-reference/troubleshooting-and-support/errors-handing.md)
* [Identifiers](/api-document/product-guides/booking/booking-overview/identifiers.md)
* [Search](/api-document/product-guides/booking/booking-step-guides/search.md)
* [Verify](/api-document/product-guides/booking/booking-step-guides/verify.md)
* [Create Order](/api-document/product-guides/booking/booking-step-guides/create-order.md)
* [Search vs Offer](/api-document/product-guides/booking/booking-overview/booking-decisions/search-vs-offer.md)