Hostaway

Each new Hostaway reservation sends the guest the agreement and waivers that listing needs, re-read from Hostaway so what they sign matches the booking.

Before you start

• A SignSealer account with the terms signed and a published form for each document.
• Access to Hostaway's settings, to create an API key.
• Requirements that say what each listing's bookings need.

Connect Hostaway

1. In Hostaway, open Settings → Hostaway API and press Create. Choose Hostaway Public API as the partner. Copy your account ID and the API key.
2. In SignSealer, open Integrations, choose Hostaway → Connect, and paste both.
3. Choose the settings and press Connect Hostaway. SignSealer exchanges the key for a token (proving it) and registers a unified webhook with a login and password it made for this connection.
4. Make a test reservation in Hostaway and watch it arrive under the connection's activity.

What SignSealer sets up in Hostaway

One unified webhook (POST /v1/webhooks/unifiedWebhooks) pointing at this connection's delivery address, with a Basic Auth login and password generated for it. Hostaway sends reservation created, reservation updated and new-message events to it; messages are accepted and ignored.

What comes across

Hostaway	In SignSealer	Notes
id	Reservation external ID
listingName, channelReservationId	Label
arrivalDate / departureDate	Starts on / ends on
guestFirstName + guestLastName, guestEmail, phone	Primary guest	Recognised on update by the Hostaway guest ID
numberOfGuests, adults, children, pets	Facts: guests, adults, minors, pets
channelName or source	Fact: channel
listingMapId	Facts: property, property_name
status	What happens	new, modified: worked · inquiry, pending, owner stays: ignored · cancelled, declined, expired: cancelled

Requirements that read it

The reservation carries these facts, which a requirement's condition can read: guests, adults, minors, pets, channel, property and property_name. 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

Hostaway does not sign its webhooks. SignSealer registers the webhook with a login and password of its own and refuses any delivery without them (compared in constant time), at an address whose 64-character token is itself a secret. Neither proves the delivery's contents, so the delivery is used only to learn which reservation changed, and the reservation is always read back from Hostaway's API. A forged delivery can at most make SignSealer re-read one of your own reservations. Hostaway also delivers from fixed addresses; SignSealer does not rely on them.

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
“Hostaway refused our credentials”	The account ID or key is wrong, or the key was deleted	Create a new key for Hostaway Public API and paste it
Needs attention after it worked	The key was revoked in Hostaway	Paste a new key on the connection's page
Deliveries show 401 in Hostaway	The webhook was edited in Hostaway and lost SignSealer's login	Press New address; SignSealer registers a fresh webhook with a new login
A guest got nothing	No email on the reservation, or no requirement applies	The activity names the guest and the reason

Hostaway's limits

Hostaway allows 200 requests per 10 seconds per account; SignSealer makes one read per reservation change and keeps its token, which Hostaway issues for months, sealed. Hostaway retries a delivery up to three times within about an hour, only after a network error, a 5xx or a 429, and treats other 4xx answers as final; SignSealer answers 200 as soon as a delivery is recorded.

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.