Make

Watch for a signature in Make and branch on it, or send a form from any module's data — with the same API, and the same evidence, as everything else in SignSealer.

What the app does

Module	Kind	Calls
Watch Signing Events	Instant trigger (dedicated webhook)	Attaches with POST /v1/webhooks for the event you choose; detaches with DELETE /v1/webhooks/{id}?reason=
Send a Form to Sign	Action	POST /v1/workflows/{id}/start
Add or Update a Reservation	Action	PUT /v1/subjects
Send What a Reservation Owes	Action	POST /v1/packets/{id}/start — safe to repeat
Search Documents	Search	GET /v1/documents

Connecting

Create an API key under Developers → API keys with the Read, Write, Workflows, Subjects and Webhooks scopes, and paste it when Make asks. It is checked against GET /v1/account, whose business name labels the connection, and kept out of Make's logs.

Until the app is listed

Make's HTTP → Make a request module does the same job with that key. For a trigger, create a Custom webhook in Make and add its address as a webhook in SignSealer for the event you want.

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

{ "provider": "make", "external_id": "BK-1042", "starts_on": "2026-10-10",
  "participants": [{ "ref": "g1", "full_name": "Sam Tan", "email": "sam@example.com", "is_primary": true }] }

Then POST /v1/packets/{packet_id}/start sends what the reservation owes. Both are safe to repeat.

For SignSealer: publishing

The app's source is integrations/make (Make's Apps SDK layout). Deploy it with the Apps SDK extension for VS Code, then submit it for Make's review.

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.