For the complete documentation index, see llms.txt. This page is also available as Markdown.

205 vs 299 vs 304

How Atlas transient verify and order failures 205, 299, and 304 differ, and when to retry once, restart from search, or escalate.

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

Ask Eva

Use this page when verify or order creation fails and the response looks transient rather than clearly caused by input or stale identifiers.

Short answer

205 is a verify timeout.

299 is a transient verify failure.

304 is a transient order-stage failure.

All three can be retryable, but not in blind loops.

FAQ

What does 205 usually mean?

It means verify.do timed out.

Retry once after a short wait.

What does 299 usually mean?

It means verify failed due to a transient platform or airline-side condition.

Retry verify once.

Then restart from search if needed.

What does 304 usually mean?

It means order creation hit a transient platform or airline-side issue.

Retry carefully.

Escalate if it repeats.

Core difference

205 — verify timeout

Failed stage

verify.do

What it usually means

The verify response took too long.

Next action

Retry verify once after a short wait.

299 — transient verify failure

Failed stage

verify.do

What it usually means

Atlas or the airline hit a short-lived operational problem.

Next action

Retry verify once.

If it repeats, restart from search.do.

If it still repeats, escalate.

304 — transient order-stage failure

Failed stage

order.do

What it usually means

Order creation hit a transient platform or airline-side problem.

Next action

Retry carefully.

If repeated, escalate with request context.

Quick decision rule

Use this rule in production:

  • 205 — retry verify once after a short wait

  • 299 — retry verify once, then restart from search if needed

  • 304 — retry carefully, then escalate if repeated

What to avoid

Do not treat these codes like stale-identifier errors.

Do not restart the whole flow immediately on the first transient failure.

Do not run unlimited retry loops.

Common mistakes

Treating 205 like 202

Do not do this.

205 is a timeout, not an expired routingIdentifier.

Treating 299 like a hard input error

Do not do this.

It is usually a transient operational problem.

Retrying 304 aggressively in parallel

Do not do this.

Careless retries can create duplicate or unclear booking outcomes.

Best practice

Use controlled retry.

Keep request timestamps, identifiers, itinerary summary, and passenger mix in logs.

If the same transient code repeats, escalate with that context.

Last updated

Was this helpful?