> 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/429-vs-110.md).

# 429 vs 110

{% 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 you need to understand the difference between Atlas error code `429` and Atlas error code `110`.

### Short answer

`429` is an Atlas request-limit error code.

`110` is an Atlas business error for too many concurrent search requests.

Both mean request frequency is too high.

They are not the same signal.

### FAQ

#### What does error code `429` mean?

It means the current request rate exceeded the configured request-limit policy.

Use `retryAfter` before retrying.

#### What does error code `110` mean?

It means search concurrency is above the allowed level.

This is an Atlas business response in the search flow.

#### Which one should I expect on over-limit traffic?

Expect `429` when request-limit governance rejects the call.

Expect `110` when the search flow enters Atlas business processing and then fails because concurrent search pressure is too high.

### Core difference

#### `429`

This is an Atlas request-limit error code.

It tells you the active limit bucket and how long to wait.

Typical fields include:

* `code`
* `message`
* `limitType`
* `limit`
* `retryAfter`

#### `110`

This is an Atlas business code.

It means the search flow is under too much concurrent request pressure.

It does not carry the same request-limit payload as `429`.

### How to handle each one

#### On `429`

* wait for `retryAfter`
* reduce burst size
* collapse duplicate requests
* avoid immediate parallel retry

#### On `110`

* add back-off before retrying
* lower search concurrency
* reduce duplicate searches
* contact Atlas if your traffic pattern needs a higher tier

### Which APIs are affected?

#### `429`

Atlas can return `429` for selected pre-booking APIs under request-limit governance.

Common pools include:

* `search.do`
* `verify.do`
* `getOffers.do`
* `seatAvailability.do`
* `getLuggage.do`

#### `110`

`110` is a search-flow problem.

Treat it as specific to search concurrency.

### Retry guidance

#### Retry `429`

Retry only after the returned `retryAfter` delay.

Then retry with lower frequency.

#### Retry `110`

Retry only after adding back-off and reducing concurrency.

Do not hammer the same search in tight loops.

### Quick decision rule

Use this rule in production:

* if the returned code is `429`, honor `retryAfter`
* if the business code is `110`, slow down search concurrency first

For both cases, improve cache reuse and suppress duplicate search bursts.

### Common mistakes

#### Treating `110` like a normal timeout

Do not retry it immediately like `112`.

`110` means traffic pressure, not a simple transient timeout.

#### Ignoring `retryAfter` on `429`

Do not retry before the returned delay expires.

Immediate retry usually causes another `429`.

### Related pages

* [Error Codes](broken://spaces/6LsKtmbJhZxgxraY5mHB/pages/Jk40OgfAM5G1NDZxwAS1)
* [Search Errors](broken://spaces/6LsKtmbJhZxgxraY5mHB/pages/ZZXG9HGTENPgRVyaaoYs)
* [API Request Limits](broken://spaces/6LsKtmbJhZxgxraY5mHB/pages/EsovwRrOMFnJMFfWhnMV)
* [Search](broken://spaces/6LsKtmbJhZxgxraY5mHB/pages/9K7uEnLGfEbpjGjni5gD)
* [Search & Booking](broken://spaces/6LsKtmbJhZxgxraY5mHB/pages/XrP8GBROs9JgYdkjYKPj)