Pipedrive
When a Pipedrive deal reaches your contract stage, its person is sent your agreement; when they sign, a note on the deal says so. Today through Zapier or Make.
Planned. Built, and not yet connectable. The native connection is written against Pipedrive's documentation and tested against stand-ins: you press Send for a deal and choose what goes, or name a stage that sends it, to its person and participants, a lost or deleted deal voids what nobody signed, and a note goes on the deal when they have signed. It has not run against a live Pipedrive account, and it cannot be connected until SignSealer's Pipedrive app exists and passes Pipedrive's Marketplace review. Until then Zapier and Make carry both directions, and the guide has the exact steps.
Today, step by step
- In Zapier: trigger on Pipedrive's Updated Deal Stage, then SignSealer's Send a Form to Sign. In Make: Watch Deals, then Send a Form to Sign.
- A second Zap or scenario: SignSealer's Document Completed, then Pipedrive's Create Note on the deal.
- Use the deal ID as your reference so each document leads back to its deal.
The signature coming back
A second Zap or scenario: SignSealer's Document Completed or Document Declined (or a SignSealer webhook) → Pipedrive's Create Note on the deal, found by the deal ID you sent as the reference. A declined document carries the signer's reason.
What the native connection does
It is built, and waits on SignSealer's Pipedrive app. Connecting will be
approving SignSealer in Pipedrive. SignSealer then registers a webhook of its own for your company's deals, which
Pipedrive calls with a login and password only that connection holds, and reads each deal back from Pipedrive's API
rather than trusting what the webhook said. A deal goes when somebody sends it: on the connection's page in
SignSealer, paste the deal's id or the address of its page, then choose what goes, any of your templates and forms, or what your rules say it needs, and whether to the
deal's person or everyone on it, won deals included. An open deal at one of the stages you name (by the name Pipedrive
shows, or by number; none until you name one) sends what its person and its participants owe, the deal's person first. A lost
or deleted deal voids what nobody has signed, unless you switch that off; a won deal is left alone. When every
document is signed, or one is declined, a note goes on the deal listing each document, who signed it and a link to
it, and when everything is signed each signed PDF is added to the deal's files (a switch on the connection turns that
off). It never changes a deal's value. On the connection's page you can choose where a signed deal goes, won
to mark it won or a stage by name or number (not one that sends or cancels), and a deal field of your own, a text field
or a single option field with options called Signed and Declined, that says which; both are off until you fill them in,
and one Pipedrive refuses is said in the connection's activity while the note still goes. Pipedrive tells SignSealer only about deals the person who
connected it can see. Disconnecting takes the webhook down; SignSealer's app stays in Pipedrive until you uninstall
it there.
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": "pipedrive", "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 Pipedrive 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 10 agreements a month.
Get an API key