Error Response Format
Every error response follows the same structure:| Field | Always Present | Description |
|---|---|---|
status | Yes | Always "error" |
code | Yes | Machine-readable error code (use this for programmatic handling) |
message | Yes | Human-readable description (may change — don’t parse this) |
field | No | Which field caused the error (only on validation errors) |
requestId | Yes | Unique request ID for support inquiries |
Error Codes
| HTTP Status | Code | Description |
|---|---|---|
| 400 | INVALID_JSON | Request body is not valid JSON |
| 400 | FIELD_REQUIRED | A required field is missing. The field property tells you which one. |
| 400 | FIELD_INVALID | Field value is invalid (wrong type, out of range, too long, etc.) |
| 401 | UNAUTHORIZED | Missing or invalid API key. See Authentication. |
| 401 | KEY_REVOKED | API key has been revoked by the hotel admin |
| 404 | GUEST_NOT_FOUND | No active guest with the given pmsGuestId |
| 409 | ROOM_OCCUPIED | Room already has an active guest. Response includes currentGuest info. |
| 409 | DUPLICATE_GUEST | An active guest with the same pmsGuestId already exists |
| 422 | INVALID_DATE_FORMAT | Date is not in ISO 8601 format (YYYY-MM-DD) |
| 422 | INVALID_PHONE_FORMAT | Phone number is not in E.164 format |
| 422 | ROOM_NOT_FOUND | Room number doesn’t exist in the hotel’s configured room list |
| 429 | RATE_LIMITED | Too many requests. See Retry-After header and Rate Limits. |
| 500 | INTERNAL_ERROR | Server error. Contact support with the requestId. |
Validation Rules
Every field is validated on the server. Here are the rules for each field:| Field | Type | Constraints |
|---|---|---|
pmsGuestId | string | Required. 1–255 characters. Must be unique among active guests. |
lastName | string | Required. 1–100 characters. |
firstName | string | Optional. 1–100 characters. |
roomNumber | string | Required for check-in. Must match a room in the hotel’s configured room list. |
phone | string | Optional. Must be E.164 format (see below). |
checkInDate | string | Optional (defaults to today). Must be YYYY-MM-DD. |
checkOutDate | string | Required for check-in. Must be YYYY-MM-DD. Must be on or after checkInDate. |
language | string | Optional. ISO 639-1 code: en, tr, de, fr, es, ru, etc. |
nationality | string | Optional. ISO 3166-1 alpha-2 code: US, TR, DE, etc. |
email | string | Optional. Must be a valid email format. |
notes | string | Optional. Maximum 2,000 characters. |
adults | integer | Optional. Range: 1–20. Defaults to 1. |
children | integer | Optional. Range: 0–20. Defaults to 0. |
Date Format
Strict ISO 8601. No exceptions.| Format | Example | Status |
|---|---|---|
YYYY-MM-DD | 2026-02-18 | Accepted |
DD.MM.YYYY | 18.02.2026 | Rejected (422) |
MM/DD/YYYY | 02/18/2026 | Rejected (422) |
DD-Mon-YYYY | 18-Feb-2026 | Rejected (422) |
| Unix timestamp | 1708214400 | Rejected (422) |
Phone Number Format
E.164 format required. Starts with+, followed by country code and number. No spaces, dashes, or parentheses.
| Example | Status | Why |
|---|---|---|
+905551234567 | Accepted | Correct E.164 |
+491234567890 | Accepted | Correct E.164 |
+442071234567 | Accepted | Correct E.164 |
05551234567 | Rejected | Missing country code (+90) |
+90 555 123 4567 | Rejected | Contains spaces |
0090-555-123-4567 | Rejected | Contains dashes and leading zeros |
(555) 123-4567 | Rejected | US local format — not E.164 |
Common Mistakes
Sending dates in DD.MM.YYYY format
Sending dates in DD.MM.YYYY format
This is the most common error for Turkish PMS integrations. Protel, Byte, and Hicell all default to
DD.MM.YYYY internally.Fix: Convert all dates to YYYY-MM-DD before sending. For example, 18.02.2026 → 2026-02-18.Missing country code on phone numbers
Missing country code on phone numbers
Sending
05551234567 instead of +905551234567. The phone field requires the full international number with country code.Fix: Prepend the country code with +. For Turkey, that’s +90. For Germany, +49. For the UK, +44.Sending roomNumber as an integer
Sending roomNumber as an integer
Sending
{"roomNumber": 301} instead of {"roomNumber": "301"}. Room numbers are strings because they can contain letters (e.g., "301A", "P2-105").Fix: Always send room numbers as strings: "301", not 301.Forgetting the Idempotency-Key header
Forgetting the Idempotency-Key header
All POST endpoints require an
Idempotency-Key header. Without it, you’ll receive a 400 error.Fix: Include Idempotency-Key: your_unique_key in every POST request. See Idempotency for key format recommendations.Reusing the same Idempotency-Key for different operations
Reusing the same Idempotency-Key for different operations
Each unique operation needs its own key. If you use the same key for two different guests, the second request will return the first guest’s cached response.Fix: Use a key format like
{operation}_{pmsGuestId}_{date}. Example: checkin_RES2026001_20260218.Checking in a guest without checking out the previous one
Checking in a guest without checking out the previous one
Handling Errors in Your Code
Here’s a recommended error handling pattern:Retry guidance:
- 4xx errors (except 429): Fix your request before retrying. Retrying the same payload will return the same error.
- 429 errors: Wait for the
retryAfterperiod, then retry. - 5xx errors: Retry with exponential backoff (1s, 2s, 4s, 8s). Include the
requestIdif contacting support.