Integrations

A booking system sends SignSealer each reservation; your requirements decide what each guest signs; the guest is sent it. Nobody re-types a name, and nothing already sent is sent again.

System	Kind	Status
Guesty	Vacation rentals	Beta
Hostaway	Vacation rentals	Beta
FareHarbor	Tours and activities	Awaiting partner approval
Hospitable	Vacation rentals	Awaiting partner approval
Zapier	Automation	Beta
Make	Automation	Beta
Lodgify	Vacation rentals	Planned
Hostfully	Vacation rentals	Planned
Peek Pro	Tours and activities	Planned
HubSpot	CRM	Planned
Zoho CRM	CRM	Planned

Beta means a customer can connect it today, built against the provider's published API and tested against it on our side. Awaiting partner approval means it is built and the provider has to approve SignSealer before anyone can connect it. Planned means not built; each of those guides shows how to get the same result today with Zapier, Make or the API.

How a connection works

1. You connect it under Integrations in the dashboard, with credentials you create in the provider. SignSealer checks them with the provider before keeping anything, then registers its webhook there when the provider allows that.
2. The connection is a key. Each connection owns an API key of its own, scoped to reservations and signing, whose secret nobody holds. Everything the integration does in your account is done as that key, through the same checks as the API, and the activity log names it. Disconnecting revokes it.
3. The provider tells SignSealer. Each connection has its own delivery address. A delivery is proven to be the provider's before anything in it is read — by signature where the provider signs, otherwise by the address's secret plus reading the booking back from the provider's API.
4. The booking becomes a reservation. A worker reads the booking as it is now, then writes the reservation, its guests and its packet, exactly as PUT /v1/subjects would.
5. Your requirements decide. The packet lists what each guest owes. The connection sends it straight away or waits for you.

Secrets

A connection's credentials, the provider's webhook secret, the access token SignSealer was issued and the delivery address's token are sealed together with the same key that seals every other credential, and are never shown again after you enter them. The address token is kept as a hash for lookup; somebody who can manage the connection can read the address again, because some providers (FareHarbor) are set up by email.

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.

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.

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.

Versions and deprecation

Each provider row records the version of SignSealer's connector and the provider API version it is built against, and each connection records what it last ran with. When a provider deprecates an API version we depend on, the provider's row carries the date it is deprecated and the date it goes away, the change is written to the activity log of every business connected to it, and it shows on the Integrations screen.

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.

Zapier, Make and your own code

Every integration here is built on the public API. Anything these pages do, your code can do with PUT /v1/subjects, POST /v1/packets/{id}/start, POST /v1/packets/{id}/void and webhooks — Reservations and packets walks through it.