Common hotel API error patterns
- 4xx client errors: 400 malformed request, 401 authentication failure, 403 permission denied, 404 property or booking not found, 409 concurrent modification conflict, 429 rate limit exceeded.
- 5xx server errors: 500 supplier internal error, 502 upstream gateway error, 503 supplier maintenance, 504 timeout.
- Business-level errors (often returned as 200 with error payload): rate no longer available, room sold out, invalid date range, no availability, cancellation policy violation.
Retry strategy by error type
| Error type | Retry? | Strategy |
|---|---|---|
| 429 Rate limit | Yes | Exponential backoff with jitter, honor Retry-After header |
| 500 / 502 / 503 / 504 | Yes | 3 retries with exponential backoff |
| 401 / 403 | No | Alert operations, refresh credentials, fail request |
| 400 / 404 | No | Return error to user, log for analysis |
| 409 Conflict | Sometimes | Refresh cache, re-query, retry once |
| Business errors | No | Handle in application logic, present clear message to user |
Partial failures across multiple suppliers
When your app queries multiple suppliers in parallel, one supplier can fail while others succeed. Do not fail the whole request. Return the successful results and log the partial failure for later analysis.
Vervotech handles this automatically. When one downstream supplier fails on a multi-supplier search, Vervotech returns the successful results and logs the failed supplier for observability.
Frequently asked questions
How should I handle 429 rate limit errors?
Exponential backoff with jitter. Honor the Retry-After header if present. Alert operations if 429 rate becomes sustained.
What error codes should I always log?
Log every 5xx and every 4xx that indicates a client bug (400 malformed request, 401 auth failure). Do not log 404 for expected "not found" queries.
See it in one Vervotech trial
7-day free trial. 400+ suppliers through one API. No credit card.
Product Tour