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.
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 wait299— retry verify once, then restart from search if needed304— 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.
Related pages
Last updated
Was this helpful?