Questions partners have asked while integrating, with the answers given. Where an answer is a figure or a list that can change, it lives on the page that owns it and is linked from here rather than repeated.
The boolean fields are listing.petsAllowed, protection.hasPetProtection and protection.isPerStay. Each takes a JSON boolean, true or false.
The strings "true" and "false" are also accepted, in any casing and with surrounding spaces ignored. An empty string counts as not supplied.
Any other value, such as "yes" or 1, is rejected with petsAllowed must be a boolean value. or hasPetProtection must be a boolean value. The exception is isPerStay, where any value other than true, including an absent one, prices the protection per night.
Sandbox runs the same release as production, through the same gateway and the same policies, so validation is identical.
There is one deliberate difference, and it matters for testing. The watch-list guest used to produce a Rejected outcome is seeded in sandbox only. The same details in production are not on the watch list and will not produce a rejection.
See Producing each outcome in the sandbox on Create a verification request. The same values work on Screening Only.
No. All testing is done in sandbox, including anything for a soft launch. The test guests exist in sandbox only, and every screening in production is a real screening.
The data available is the response to each request, and the current record of any verification the integration created, through Retrieve a verification request. There is no access to logs or to the database.
Send the echoToken and the time of the request, and it can be traced from our side. Those two together identify a single request, which is why the token is worth recording against whatever the request was for. For a 500, send the reference code in detail as well.
No. Neither slow responses nor date-dependent outcomes can be simulated.