—Guidebooks and check-in apps
Guidebooks are good at helping guests arrive smoothly. PreArrive adds the narrow compliance step before that experience: every rule and fee is acknowledged, signed, and stored as a certificate before selected arrival details are released.
01Integration fit
02API building blocks
The public API and webhooks are Pro-tier features. Partner distribution, custom data-processing terms, or co-selling may require a separate agreement beyond self-serve Pro.
Create and update the PreArrive property records that map to listings or units in the partner system.
POST /v1/properties
Read or replace the rules, fees, arrival fields, and release settings attached to a property packet.
GET /v1/properties/{id}/packet
Create reservations, send or resend signing links, cancel stays, and read signed status by reservation id.
POST /v1/reservations
Poll `GET /v1/reservations/{id}` or filter `GET /v1/reservations?status=signed` when a polling workflow is simpler than webhooks.
GET /v1/reservations/{id}
Retrieve certificate metadata, audit fields, verification URL, and the PDF download redirect after a reservation is signed.
GET /v1/certificates/{id}/download
Register signed outbound webhook endpoints and inspect delivery attempts, retries, and redelivery history.
POST /v1/webhook_endpoints
03Workflow recipes
These are the workflows most partners need first: create the stay, send the packet, wait for signed status, react to arrival-release events, and retrieve the certificate. Arrival-release control belongs in the partner, PMS, lock, or guidebook system that already owns the guest access workflow.
Create and send a signing packet
Create or find the matching PreArrive property with `POST /v1/properties` or `GET /v1/properties`.
Create the reservation with `POST /v1/reservations` using guest name, guest email, check-in, checkout, and source.
Send the guest link with `POST /v1/reservations/{id}/send`.
Check signed status and fetch the certificate
Read the reservation with `GET /v1/reservations/{id}` and wait for `status: signed` and `signature_id`.
Retrieve audit metadata with `GET /v1/certificates/{signature_id}`.
Download the PDF through `GET /v1/certificates/{signature_id}/download`.
Release arrival details after signature
Set `packet.arrival_release` so WiFi, door codes, parking, or guidebook sections are marked `after_signing` when they should be held.
Subscribe a signed webhook endpoint to `reservation.arrival_details_held`, `reservation.arrival_details_released`, `reservation.arrival_details_viewed`, and `reservation.arrival_details_override_released`.
Verify `PreArrive-Signature`, then treat `reservation.arrival_details_released` as the external unlock trigger for the partner-owned door code, WiFi, guidebook section, or check-in message.
When `reservation.arrival_details_override_released` arrives, preserve the override reason in your own audit log and release only the partner-owned details your workflow controls.
Keep emergency and safety instructions visible through your own system regardless of signature state.
property.createdproperty.updatedproperty.deletedpacket.updatedreservation.createdreservation.sentreservation.openedreservation.clickedreservation.signedreservation.cancelledreservation.arrival_details_heldreservation.arrival_details_releasedreservation.arrival_details_viewedreservation.arrival_details_override_releasedcertificate.createdsync_source.createdsync_source.updatedsync_source.run.completed04Boundaries
05Keep going
Use the Pro API and signed webhooks for the acknowledgment layer. For partner distribution, DPA terms, or a larger rollout, route the conversation with API context attached.