Ctrlk
💬 Need Help? Click Me
For the complete documentation index, see llms.txt. This page is also available as Markdown.

429 vs 110

How Atlas error code 429 differs from Atlas error code 110, what each one means, and how to respond safely.

💬 Need help? If you're stuck, ask Eva in the Help Center for instant diagnostics.

Ask Eva

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

PreviousCommon & Access Errors
NextSearch Errors

Last updated

Was this helpful?