Attach the signed acknowledgment to the claim file.

Claims teams still need photos, receipts, estimates, and timelines. PreArrive supplies the pre-stay acknowledgment artifact: the packet text, per-item taps, drawn signature, timestamps, IPs, verification URL, and content hash.

Where this integration fits.

Best-fit teams

  • STR insurance brokers building better documentation workflows for clients.
  • Claims-prep services organizing evidence packets after an incident.
  • Property managers that want signed acknowledgment links inside incident files.

Integration pattern

  • Pull signed certificates into a claims-prep portal once `certificate.created` fires.
  • Attach the verification URL and content hash alongside photos, receipts, and statements.
  • Use status polling to identify stays that are still unsigned before check-in.

What a partner can create and read.

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.

Properties

Create and update the PreArrive property records that map to listings or units in the partner system.

POST /v1/properties

Packets

Read or replace the rules, fees, arrival fields, and release settings attached to a property packet.

GET /v1/properties/{id}/packet

Reservations

Create reservations, send or resend signing links, cancel stays, and read signed status by reservation id.

POST /v1/reservations

Signed status

Poll `GET /v1/reservations/{id}` or filter `GET /v1/reservations?status=signed` when a polling workflow is simpler than webhooks.

GET /v1/reservations/{id}

Certificates

Retrieve certificate metadata, audit fields, verification URL, and the PDF download redirect after a reservation is signed.

GET /v1/certificates/{id}/download

Webhooks

Register signed outbound webhook endpoints and inspect delivery attempts, retries, and redelivery history.

POST /v1/webhook_endpoints

Common recipes, kept narrow.

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.

01

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`.

02

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`.

03

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.

Webhook events available today

  • property.created
  • property.updated
  • property.deleted
  • packet.updated
  • reservation.created
  • reservation.sent
  • reservation.opened
  • reservation.clicked
  • reservation.signed
  • reservation.cancelled
  • reservation.arrival_details_held
  • reservation.arrival_details_released
  • reservation.arrival_details_viewed
  • reservation.arrival_details_override_released
  • certificate.created
  • sync_source.created
  • sync_source.updated
  • sync_source.run.completed

What PreArrive does not become.

Partner can build

  • Reservations and sends from the client or partner workflow.
  • Signed status checks for operational follow-up.
  • Certificate metadata and PDF downloads for evidence packets.

PreArrive does not do

  • PreArrive is not a PMS or channel manager. Your operational system remains the source of truth for rates, availability, cleaning, owner accounting, and guest messaging.
  • PreArrive does not write fees, messages, claims, rates, or availability back into Airbnb, VRBO, Booking.com, or direct-booking platforms.
  • PreArrive does not provide marketplace OAuth for partner apps. API keys are Pro-account, server-to-server credentials controlled by the account owner.
  • PreArrive does not collect guest payments, security deposits, or itemized fees.
  • PreArrive does not scan IDs, verify identities, or run biometric matching.
  • PreArrive does not operate smart locks. A partner lock, PMS, or workflow tool can release its own code after receiving `reservation.arrival_details_released` or `reservation.signed`.

Docs, pricing, and related surfaces.

Ship the signature step without changing your whole stack.

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.