Docs

Docs / Integrations / Pipedrive integration

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

  1. 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.
  2. A second Zap or scenario: SignSealer's Document Completed, then Pipedrive's Create Note on the deal.
  3. 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.

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