FareHarbor

When someone books a tour in FareHarbor, the contact is sent your waiver with the activity and date filled in, so the check-in line is not a clipboard line.

Before you start

• Not yet possible: FareHarbor must approve and certify SignSealer as a software partner first.
• Until then, use the Zapier or Make route below.

Connect FareHarbor

1. Once FareHarbor has approved SignSealer, confirm SignSealer's access in FareHarbor so FareHarbor issues your API user key for it.
2. In SignSealer: Integrations → FareHarbor → Connect, with your company shortname and that user key.
3. SignSealer reads your company from FareHarbor to prove the key, then shows the delivery address.
4. Email FareHarbor support (support@fareharbor.com) asking for booking webhooks — created, updated and cancelled — to that address. FareHarbor sets webhooks up by email; there is no API for it.

What SignSealer sets up in FareHarbor

Nothing automatically: FareHarbor configures webhooks itself, by email, per company. The address SignSealer shows is the only thing to give them.

What comes across

FareHarbor	In SignSealer	Notes
booking.uuid	Reservation external ID (kind: activity)
availability.item.name, display_id	Label and fact: activity
availability.start_at	Starts on, and fact: starts_at	The operator's local date
contact.name, email, normalized_phone	Primary guest	FareHarbor names the contact, not each customer
customer_count	Fact: guests
affiliate_company or source_type	Fact: channel
status	What happens	booked: worked · cancelled or rebooked: cancelled (a rebooking arrives as a new booking)

Requirements that read it

The reservation carries these facts, which a requirement's condition can read: activity, activity_id, guests, channel and starts_at. 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

FareHarbor cannot sign webhooks or add headers to them, and advises partners to put a secret in the URL and re-fetch the booking. SignSealer does exactly that: the 64-character token in the delivery address is the secret, and every booking is read back from FareHarbor's API (with SignSealer's partner key and your user key) before anything is built from it. FareHarbor warns that duplicate deliveries are normal; each is recognised by the booking and the exact bytes, and recorded once.

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
Connect is refused: “cannot be connected yet”	FareHarbor has not approved SignSealer as a partner	Use Zapier or Make until then
Deliveries arrive but nothing is built	The user key was revoked in FareHarbor	Paste a new user key on the connection's page
Changing a booking's note re-triggers it	FareHarbor sends a webhook for every change, including notes	Harmless: nothing already sent is sent again

Today, without partner access

Zapier and Make both reach FareHarbor through FareHarbor's own notification emails or booking exports. Pass each booking to SignSealer's Add or Update a Reservation with kind activity, the booking's UUID as the booking ID, the activity date and the contact — your requirements then decide the waiver. Or send your waiver form's link in FareHarbor's confirmation email.

A note on consent

FareHarbor's is_subscribed_for_sms_updates means the contact wants texts from FareHarbor about the booking, and FareHarbor's own documentation says it does not reflect a STOP. It is not consent to texts from you through SignSealer and is never read as one.

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.