POST /verificationRequests

Before integrating

Six things to watch out for

1. The boolean fields are JSON booleans, and every other field is a string. petsAllowed, hasPetProtection and isPerStay take true or false. A JSON number sent where a string is declared, such as "numberOfGuests": 4, is accepted and converted on arrival, so 4 and "4" are equivalent.
2. A verification 200 response returns a verification.status of Approved, Flagged or Rejected. The status code says whether the request was processed, not what the outcome was.
3. echoToken must be a fresh GUID on every request. Reusing one returns 400. That is what makes retries safe: a retried request that already succeeded cannot create a second verification. The token is echoed back on responses and errors, so it is the reference to quote when support is needed. Keep a copy: a body that cannot be read, and some unexpected errors (500), return Unknown in its place.
4. On the OTA channels, guest.telephoneNumber is always required, even when an email address is supplied, except on booking.com, where guest.email is required and the telephone number is optional. On every other channel, either an email address or a telephone number will do.
5. checkIn must be today or later, and must be before checkOut, so a same-day stay is rejected.
6. The grace period allows a check-in date that has just passed, and it is applied to the date rather than the time: a checkIn of yesterday is accepted until 12:00 UTC and rejected from 12:00 UTC onwards. Depending on the hour a request arrives, that makes the tolerance anywhere between 12 and 36 hours.

Request

Content-Type: application/json, with the subscription key in the Ocp-Apim-Subscription-Key header.

The body carries six objects, all required: metadata, company, listing, reservation, guest and protection.

For a string field, the Format column below describes what the value must contain, not the JSON type it must be sent as.

Dates and timestamps

JSON has no date type, so dates and timestamps are strings. The date and date-time entries in the Format column describe what the string must contain.

Both formats are matched exactly. A value that is a correct date but written differently is rejected.

Three points worth noting:

• No timezone designator. A trailing Z or an offset such as +01:00 is rejected. The time is taken as UTC.
• Exactly two fractional-second digits. Three digits (the usual default for milliseconds) is rejected, and so is omitting the fractional part altogether.