PUT /verificationRequests

Before integrating

Six things to watch out for

  1. Only the dates and the pet flags can be changed. Guest details, company, listing details, channel, and protection type and amounts cannot be changed here. If they are sent, they are ignored and the request still succeeds. A verification is never re-screened by a modify, so the outcome it was given at creation stands, and changing the dates does not change what is charged.
  2. The response carries no verification. A successful modify returns the echoed metadata and nothing else: no status, no identifier, no confirmation of what changed. The 200 is the confirmation.
  3. Both dates are required even when only one is changing. checkIn and checkOut must both be sent, with the values the reservation should end up with.
  4. verificationId identifies the record, and reservationId must match the one stored against it. A mismatch returns 404, not a validation message.
  5. A stay that has started can still be modified. Modification closes when the check-out passes. See What can still be modified, and when below.
  6. echoToken must be a fresh GUID on every request, exactly as on create. Reusing one returns 400. On a timeout, retry with the same echoToken: if the original request succeeded, the retry returns 400 echoToken (<the token>) already exists from a previous request, which confirms the modification was applied rather than reporting a failure.

Request

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

The body carries five objects. metadata, verification and reservation are required; listing and protection are optional and may be omitted entirely.

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 use the same exact formats as create: yyyy-MM-dd for dates and yyyy-MM-ddTHH:mm:ss.ff for the timestamp, both matched exactly, with no timezone designator and exactly two fractional-second digits.

metadata

Level Field Name Required Format Value Set Description
1 metadata True object Carries timeStamp and echoToken. Sent on every request and echoed on every response and error.
2 timeStamp True date-time yyyy-MM-ddTHH:mm:ss.ff Timestamp in ISO format yyyy-MM-ddTHH:mm:ss.ff, for example 2026-09-03T14:31:07.42. On a request this is the client's; on a response and on an error it is the server's.
2 echoToken True string 36 Char A GUID of exactly 36 characters, unique to the request. Reusing one returns 400, which makes retries safe. Responses and errors echo back the token the client sent, or 'Unknown' when it could not be read (a body the parser rejects, or one without metadata) and on some unexpected errors (500).

verification

Level Field Name Required Format Value Set Description
1 verification True object The verification to modify or cancel.
2 verificationId True string 36 Char Identifier of the verification to modify or cancel. Exactly 36 characters, and must be a GUID.

reservation

Level Field Name Required Format Value Set Description
1 reservation True object The reservation's new dates. Both are required even when only one is changing.
2 reservationId True string 1-200 Char Identifier of the reservation. 1-200 characters.
2 checkIn True date yyyy-MM-dd Check-in date, yyyy-MM-dd. Must be before checkOut. A check-in already in the past cannot be modified, and a future check-in cannot be moved into the past.
2 checkOut True date yyyy-MM-dd Check-out date, yyyy-MM-dd. Must be today (UTC) or later. A check-out of yesterday is also accepted until 12:00 UTC.