Hospitable

A reservation in Hospitable sends the guest the rental agreement for that property, and your automated messages stay exactly as you set them in Hospitable.

Before you start

• Not yet possible: Hospitable must approve SignSealer as a vendor before OAuth and its partner webhooks exist for us.
• Until then, use the Zapier or Make route below.

Connect Hospitable

1. Once approved: in SignSealer, Integrations → Hospitable → Connect sends you to Hospitable to approve SignSealer. No key changes hands.
2. Hospitable's partner webhooks then deliver your reservation events to SignSealer.

What SignSealer sets up in Hospitable

Nothing in your account: a vendor's webhooks are configured once, in Hospitable's partner portal, for every customer.

What comes across

Hospitable	In SignSealer	Notes
id	Reservation external ID
property.name, code	Label
arrival_date / departure_date	Starts on / ends on
guest.first_name + last_name, email, phone_numbers[0]	Primary guest
guests.total, adult_count, child_count, pet_count	Facts: guests, adults, minors, pets
platform	Fact: channel
reservation status	What happens	accepted: worked · request, inquiry: ignored · cancelled: cancelled

Requirements that read it

The reservation carries these facts, which a requirement's condition can read: guests, adults, minors, pets, channel and property. For example, a waiver for every adult on stays with more than six guests:

{ "fact": "guests", "op": "gt", "value": 6 }

Rules are set under Requirements in the dashboard or through the API; see Reservations and packets.

How a delivery is proven

Hospitable signs each delivery with a Signature header: the hex HMAC-SHA256 of the exact body under the vendor's webhook secret, checked in constant time before the body is read. It carries no timestamp, so a captured delivery could be replayed; the event id makes a replay a duplicate, and the reservation is always read fresh from Hospitable's API.

Settings

Setting	Choices	What it does
When a booking arrives	Send straight away (default) · Build the list and wait	Straight away starts everything the packet owes as soon as the booking is worked. Waiting builds the reservation and its packet and sends nothing until somebody presses Send on the reservation, or your code calls POST /v1/packets/{id}/start.
When a booking is cancelled	Void what nobody has signed (default) · Leave it	Voiding marks every unfinished document with the reason and the packet void. Anything already signed is kept: an executed waiver is evidence of what was agreed.

What each guest is sent is decided by your requirements, not by the integration: the reservation's facts (dates, guest counts, property, channel) meet your rules, and each rule says who owes what — the primary guest, every adult, or a guardian for each minor.

Texting and consent

Signing links go by email. They also go by text only when SignSealer holds that guest's consent to receive texts from your business, recorded with the exact words they agreed to — at your counter, on your booking form through POST /v1/sms-consents, or on SignSealer's own opt-in. That check runs when the link is queued (app.may_text), not in the integration.

No booking system can give SignSealer that consent, so none is treated as if it could. Each adapter records what the provider's data said — VERIFIED_CONSENT, NO_CONSENT or INSUFFICIENT_EVIDENCE — and only NO_CONSENT changes anything: the guest's number is not written at all. Every provider built so far can only ever say INSUFFICIENT_EVIDENCE. The connection's activity shows, for each guest with a number, whether the link was also texted and why not.

How to record consent you took yourself.

Duplicates, order and retries

• Once. A delivery is recorded once per connection and event id. A provider that redelivers the same event gets 200 {"duplicate": true} and nothing happens twice.
• Newest wins. Each event means "read this booking as it is now". A newer event about a booking supersedes an older one still waiting, and one booking is never worked twice at once.
• Nothing is sent twice. Guests are recognised by their id in the provider (or by address and name), so an update keeps each guest's link to what they were already sent.
• Retries. A failure is retried after 1, 2, 4, 8 … minutes, up to six hours apart, and gives up after eight tries. It is then listed, with its reason, under the connection's activity, where it can be tried again once whatever refused it is fixed.
• Refused credentials. If the provider refuses SignSealer's credentials, the connection goes to needs attention and stops working events until new credentials are given. What arrives meanwhile is kept and worked afterwards.
• Retention. What arrived is cleared thirty days after it was worked; the outcome and the reservation it made are kept.

Troubleshooting

What you see	Why	What to do
“cannot be connected yet”	Hospitable has not approved SignSealer as a vendor	Use Zapier or Make until then

Today, without vendor approval

Zapier and Make can pass a Hospitable reservation to SignSealer's Add or Update a Reservation. Or put your agreement form's link in a Hospitable automated message.

Pausing and disconnecting

Pause keeps recording what arrives and works nothing until you resume. New address stops the old delivery address at once (and re-registers the webhook with the provider where SignSealer set it up). Disconnect revokes the connection's key, clears its credentials, removes the webhook from the provider where it can, and closes the address. The reservations and documents it made stay, with where they came from.

From your own code

curl https://api.signsealer.com/v1/integrations -H "Authorization: Bearer $KEY"
curl https://api.signsealer.com/v1/integrations/$CONNECTION/events -H "Authorization: Bearer $KEY"

The first lists every provider with its status and your connections with their state; the second is what arrived from one connection and what became of it. Neither ever returns a credential, a delivery address or what arrived. Both need the signing:read scope. Connecting happens in the dashboard, where the provider confirms the credentials. See the API reference.