Documentation menu

Lodgify

Send each Lodgify guest your rental agreement today through Zapier or Make, while a native connection that reads bookings straight from Lodgify is on the list.

Planned. Planned, not built. Lodgify issues API keys to its customers and signs its webhooks, so a native connection needs no partnership; it is next after the providers already built. Until then the automation route above works. Links go by email. They go by text only to a guest whose consent to receive texts from you is on file in SignSealer: a booking system knowing a phone number is not that guest agreeing to be texted, and SignSealer never treats it as if it were.

Today, step by step

  1. In Zapier or Make, start from a Lodgify new-booking trigger.
  2. Add SignSealer's Add or Update a Reservation with the booking's ID, dates and guest.
  3. Set your requirements so each property's bookings get the right documents.

What the native integration will do

Connect with a Lodgify API key (sent as X-ApiKey); SignSealer subscribes to Lodgify's booking webhooks, verifies each delivery's ms-signature HMAC-SHA256 before reading it, and re-reads the booking. Nothing about the result changes: your requirements decide what each guest signs.

With the API directly

PUT https://api.signsealer.com/v1/subjects
Authorization: Bearer mk_live_…

{ "provider": "lodgify", "external_id": "…", "starts_on": "2026-10-10",
  "participants": [{ "ref": "…", "full_name": "…", "email": "…", "is_primary": true }] }

POST https://api.signsealer.com/v1/packets/{packet_id}/start

Keyed on the Lodgify ID, so sending the same record twice is one reservation, and starting again sends nothing already sent. See Reservations and packets and Webhooks for the signature coming back.

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.

Ready to build? An API key takes a minute in the portal, and the free plan covers the first 25 agreements a month.

Get an API key