Jobber

When a quote goes out from Jobber, the client is sent the agreement that goes with it: your terms, a work authorization, a waiver for the job site. Today through Zapier.

Today, step by step

1. In Zapier: trigger on Jobber's Quote Sent, then SignSealer's Send a Form to Sign, with the client's name and email from the quote.
2. Put the quote number in Your reference, so each document leads back to its quote.
3. A second Zap if you want one: SignSealer's Document Completed, then an email or a message to whoever books the work.

The signature coming back

Jobber's Zapier app has no step that writes to a quote, so today the signed document stays in SignSealer, found by the quote number you sent as its reference. A second Zap on SignSealer's Document Completed (or a SignSealer webhook) can email or message whoever books the work; a declined document carries the signer's reason.

What the native connection does

It is built, and waits on SignSealer's Jobber app. A quote that reaches a status you choose (by default awaiting_response, sent to the client) sends what its client owes, with the quote's number, status and total and the property's address for its documents to read. A quote archived or deleted is canceled, and at any other status a quote is left alone, so approving it or converting it to a job sends nothing again. Every delivery is checked against Jobber's X-Jobber-Hmac-SHA256 signature, and the quote is read again from Jobber's API rather than taken from the delivery. When everything is signed, or a document is declined, a note goes on the quote listing each document, who signed it and a link to it; nothing else on the quote is changed. Disconnecting in SignSealer tells Jobber, which then shows SignSealer as disconnected; disconnecting inside Jobber leaves the connection in SignSealer waiting to be connected again.

Once it can be connected, connecting it comes with the membership, like every system SignSealer connects to; Zapier, Make and the API work on Free today.

With the API directly

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

{ "provider": "jobber", "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 Jobber 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.