Kommo + Adobe Sign: Automatic Document Sending for Signature from the Pipeline
There is no native integration between Kommo and Adobe Sign. Managers create documents manually in Adobe Acrobat or Word, upload them to Adobe Sign, enter the recipient’s email — and then return to Kommo to create a task “awaiting signature.” When the document is signed, Kommo doesn’t learn about it automatically — the manager has to open Adobe Sign again, check, and manually move the deal to the next stage.
A custom integration closes this cycle: the document is generated from deal fields, sent for signature when the deal is moved to the appropriate stage, and the signing status is synced back to the deal card without any manager involvement.
Why there is no native integration
Adobe Sign has pre-built connectors for Salesforce, Microsoft Dynamics, ServiceNow, and other enterprise systems. There is no official connector for Kommo — Adobe prioritizes large CRMs with a broad enterprise customer base.
Zapier includes Adobe Sign as a trigger/action, but with limitations:
— No document templating with field substitution from Kommo
— Webhooks from Adobe Sign on signing require a paid plan
— No handling of signature decline or expiration
The Kommo marketplace has DocuSign and PandaDoc as alternatives — but if a company is already operating within the Adobe ecosystem (Acrobat Pro, Creative Cloud), switching to DocuSign creates additional costs and retraining.
What the custom integration does
Sending for signature on trigger:
— Manager moves the deal to “Contract Review” stage
— Kommo Digital Pipeline calls the backend via webhook
— Backend reads deal fields: client name, amount, terms, details
— Creates an Adobe Sign Agreement from a template via POST /agreements
— Populates fields via merge fields in the template (Adobe Sign supports {{field_name}})
— Saves the Agreement ID and signing link to the Kommo deal card
— Adobe Sign sends the client an email with the signing link (natively via Adobe Sign)
Status synchronization:
— Adobe Sign sends a webhook on every Agreement status change
— AGREEMENT_ACTION_COMPLETED -> status in Kommo: “Signed,” date of signing
— AGREEMENT_ACTION_DECLINED -> task for manager: “Client declined to sign”
— AGREEMENT_EXPIRED -> task: “Signing period expired, needs to be resent”
— Optionally: on full signing — automatic deal advancement to the next stage
Downloading the signed document:
— After AGREEMENT_ACTION_COMPLETED, backend downloads the PDF via GET /agreements/{id}/combinedDocument
— Uploads to Kommo as a deal attachment (POST /api/v4/leads/{id}/files)
— Manager sees the signed contract directly in the deal card
Working with Adobe Sign templates
Adobe Sign supports two approaches to templating:
Library Templates — pre-built documents in Adobe Sign with merge fields. When creating an Agreement from a template, pass the field values:
{
"fileInfos": [{ "libraryDocumentId": "TEMPLATE_ID" }],
"participantSetsInfo": [{
"role": "SIGNER",
"memberInfos": [{ "email": "client@example.com", "name": "John Smith" }]
}],
"mergeFieldInfo": [
{ "fieldName": "client_name", "defaultValue": "John Smith" },
{ "fieldName": "deal_amount", "defaultValue": "15000" },
{ "fieldName": "contract_date", "defaultValue": "05.05.2026" }
],
"name": "Contract #123 - John Smith",
"state": "IN_PROCESS"
}
Transient Document — upload a ready-made PDF (generated on the fly from a Word/DOCX template using python-docx or WeasyPrint) and sign it. This approach gives full control over the document, but requires PDF generation on the backend side.
For most cases, Library Templates are sufficient and simpler to maintain: the legal team edits the template in Adobe Sign, and the developer doesn’t touch the code.
Multiple signers
Adobe Sign supports sequential and parallel signing:
"participantSetsInfo": [
{
"order": 1,
"role": "SIGNER",
"memberInfos": [{ "email": "client@example.com" }]
},
{
"order": 2,
"role": "SIGNER",
"memberInfos": [{ "email": "ceo@yourcompany.com" }]
}
]
With sequential signing: the client signs first, then the document is routed to your CEO. The AGREEMENT_ACTION_COMPLETED webhook fires only after all parties have signed.
For Kommo this means: the “Signed” status in the deal card appears only when all signatures have been collected. The intermediate status (signed by client, awaiting your signature) can be tracked via the AGREEMENT_SIGNER_COMPLETED event.
Comparison with DocuSign and PandaDoc
| Parameter | Adobe Sign | DocuSign | PandaDoc |
|---|---|---|---|
| Native Kommo integration | No | Yes (marketplace) | Yes (marketplace) |
| API quality | Good | Excellent | Good |
| Templates in the UI | Yes | Yes | Yes |
| Price (5 users) | from $44/mo | from $45/mo | from $35/mo |
| Enterprise standard | Adobe / Microsoft | Widespread | More SMB-oriented |
| CRM widget | No | Yes | Yes |
If the company has no hard dependency on Adobe — Kommo + DocuSign integration or Kommo + PandaDoc offer the same capabilities with a ready-made marketplace connector and lower development cost.
Adobe Sign is justified when: the company already pays for Adobe Acrobat Pro or Creative Cloud (Adobe Sign is included), or when the legal team requires Adobe Sign specifically as a corporate standard.
Real-world case study
A consulting company project (10 managers, contracts from $5,000):
— Adobe Sign used per corporate client standard
— Before integration: preparing and sending a contract took 15–20 minutes per manager, 3–5 contracts per day
— After: manager moves deal to “Contract Review” -> contract sent automatically within 30 seconds
— Signed PDF appears in the Kommo deal card without any manager action
— Savings: ~1 hour per day for the team, just from document processing
Who benefits from this integration
Custom Kommo + Adobe Sign integration makes sense when:
— The company uses Adobe Sign as a corporate standard (and doesn’t want to switch to DocuSign)
— Contracts contain data from CRM fields (name, amount, terms, details)
— Seeing signing status in the deal card without opening Adobe Sign is important
— Multi-party contracts (multiple signers) are used
For more on custom integrations for Kommo CRM — what else can be automated via API.
Frequently asked questions
Does Adobe Sign store signed documents securely?
Yes. Adobe Sign stores all documents in encrypted form in Adobe’s cloud with a full audit trail — timestamp of every action, IP address, and signer email. This complies with eIDAS (Europe) and the ESIGN Act (US), and has legal standing in most jurisdictions. The signed PDF is downloadable via API and additionally stored in Kommo as an attachment.
How long does integration development take?
Basic integration (trigger-based sending + status update) — 2–3 weeks. Extended (multiple signers, PDF generation from a Word template, download to Kommo) — 4–5 weeks. Timeline depends on template complexity and the number of fields to populate.
Can multiple templates be used based on deal type?
Yes. The backend reads a custom field “Contract Type” from the deal and selects the corresponding Library Template ID in Adobe Sign. One webhook handler, multiple templates — the selection logic lives on the backend.
What if the client lost the Adobe Sign email?
The Adobe Sign API supports sending reminders: POST /agreements/{id}/reminders. In the custom integration this can be automated: if the status hasn’t changed after 3 days, the backend sends a reminder and creates a task for the manager.
Summary
- No native Kommo + Adobe Sign integration; no marketplace connector
- Custom integration: Library Template + merge fields from Kommo deal fields + webhook for status
- Signed PDF automatically saved to the deal card
- If there’s no dependency on Adobe — DocuSign or PandaDoc with a ready Kommo connector is simpler
- Typical development timeline — 2–4 weeks
If you use Adobe Sign and manage deals in Kommo — describe your document workflow. Exceltic.dev will assess the complexity and propose a concrete plan.