Kommo + Dropbox Sign: automatic contract sending for signature

Dropbox Sign (formerly HelloSign) is an electronic signature platform with a REST API on Basic Auth — no complex OAuth required for server-side integrations. This is one of the key differences from SignNow and DocuSign — service integrations work with an API key directly. The Kommo integration automates the full cycle: deal moved to the required stage -> document sent to the client -> CRM updated automatically after signing.

Dropbox Sign vs SignNow vs DocuSign: when to choose Dropbox Sign

Dropbox Sign wins on authentication simplicity: one API key in the header, no OAuth flow. This significantly simplifies server-side integration development. The price is lower than DocuSign with comparable functionality.

What gets synchronized

Kommo -> Dropbox Sign:
— Contact email and name from the deal -> signer in the signature request
— Deal name -> document title
— Data from custom fields -> custom_fields in the template (merge fields)
— Signing deadline -> expiration_date
— Kommo deal ID -> metadata (for reverse tracing)

Dropbox Sign -> Kommo:
— signature_request_signed event -> “Document Signed” field in the deal
— Move deal to the next pipeline stage
— Link to the signed document -> Note on the deal
— Signing date -> custom field

Architecture

Kommo Webhook: deal moved to "Signing" stage
  ↓ Backend
  1. GET /api/v4/leads/{id} + contacts
     -> name, email, data from custom fields
  2. Dropbox Sign API: POST /signature_request/send_with_template
     -> template_id + signers + custom_fields + metadata
     -> get signature_request_id
  3. Kommo: PATCH /leads/{id}
     -> update fields: ds_signature_request_id, document_sent = true

Dropbox Sign Webhook: signature_request_signed
  ↓ Backend
  1. Extract signature_request_id from payload
  2. Find kommo_deal_id via metadata
  3. Dropbox Sign: GET /signature_request/{id}
     -> get link to signed document
  4. Kommo: PATCH /leads/{deal_id}
     -> document_signed = true, stage -> "Contract Received"
  5. Kommo: POST /notes
     -> signing date + link to document

Dropbox Sign REST API: key requests

Base URL: https://api.hellosign.com/v3/. Authentication: HTTP Basic Auth, where username = API_KEY, password is empty.

Sending via template (recommended approach):

import requests
from requests.auth import HTTPBasicAuth

DS_API_KEY = 'your_api_key'
TEMPLATE_ID = 'template_id_from_dropbox_sign'
BASE_URL = 'https://api.hellosign.com/v3'

def send_for_signature(deal_id: int, client_name: str, client_email: str,
                       deal_name: str, amount: float) -> str:
    payload = {
        'template_ids': [TEMPLATE_ID],
        'subject': f'Contract for deal: {deal_name}',
        'message': f'Dear {client_name}, please find the contract attached for signing.',
        'signers': [
            {
                'role': 'Client',
                'name': client_name,
                'email_address': client_email
            }
        ],
        'custom_fields': [
            {'name': 'ClientName', 'value': client_name},
            {'name': 'DealAmount', 'value': f'${amount:,.2f}'},
            {'name': 'DealDate', 'value': str(date.today())}
        ],
        'metadata': {
            'kommo_deal_id': str(deal_id)  # for reverse tracing
        }
    }

    resp = requests.post(
        f'{BASE_URL}/signature_request/send_with_template',
        auth=HTTPBasicAuth(DS_API_KEY, ''),
        data=payload  # form-encoded, not JSON
    )
    return resp.json()['signature_request']['signature_request_id']

Important note: The Dropbox Sign API accepts application/x-www-form-urlencoded or multipart/form-data, not application/json for most endpoints. This is a common mistake on first connection.

Sending a document directly (without a template):

def send_document_directly(client_name: str, client_email: str,
                           pdf_path: str, deal_name: str) -> str:
    with open(pdf_path, 'rb') as f:
        resp = requests.post(
            f'{BASE_URL}/signature_request/send',
            auth=HTTPBasicAuth(DS_API_KEY, ''),
            files={'file[0]': (pdf_path, f, 'application/pdf')},
            data={
                'title': deal_name,
                'signers[0][email_address]': client_email,
                'signers[0][name]': client_name,
                'signers[0][order]': 0
            }
        )
    return resp.json()['signature_request']['signature_request_id']

Webhook handling:

from flask import Flask, request
import json

app = Flask(__name__)

@app.route('/webhooks/dropbox-sign', methods=['POST'])
def dropbox_sign_webhook():
    # Dropbox Sign sends JSON in the 'json' field
    payload = json.loads(request.form.get('json', '{}'))

    event_type = payload.get('event', {}).get('event_type')
    sr_id = payload.get('signature_request', {}).get('signature_request_id')
    metadata = payload.get('signature_request', {}).get('metadata', {})

    if event_type == 'signature_request_signed':
        deal_id = metadata.get('kommo_deal_id')
        if deal_id:
            update_kommo_deal(int(deal_id), signed=True)

    return 'Hello API Event Received'  # Dropbox Sign requires exactly this response

Critical: Dropbox Sign requires a 200 OK response with the body Hello API Event Received — otherwise it will retry the webhook up to 5 times.

Setting up a template in Dropbox Sign

Templates are created in the Dropbox Sign UI. For automatic filling you need to:

1. Add text fields with names: ClientName, DealAmount, DealDate
2. Assign the “Signature” field to the Client role
3. Save the Template ID — it is used in API requests

The template approach eliminates PDF generation on the backend side — data from Kommo is substituted into the template via custom_fields.

Real-world case

IT company (EU market, 25–35 contracts per month, clients in Germany and the Netherlands):

• Before: the manager manually downloaded the contract template, filled in the data, uploaded it to Dropbox Sign, added the recipient, and sent it. Updating Kommo was manual after signing.
• After: Won in Kommo -> the manager sees the “Document Signed” field within 30 minutes (client signing time) -> the stage transitions automatically. The manager does nothing except close the deal.
• Additional benefit: the lawyer automatically receives signed contracts by email — no longer needs to request them from managers.

Similar logic has been implemented for Adobe Sign and Kommo — that uses OAuth authentication; here it is simpler: API Key.

Who this is relevant for

• Using Dropbox Sign or considering it as a more affordable alternative to DocuSign
• 10+ contracts per month sent manually
• Need a simple API integration without OAuth complexity (for a small team)
• eIDAS (EU) or ESIGN (US) — legally significant signatures
• Two-way cycle: Won -> document -> signature -> next pipeline stage

Frequently asked questions

Does the Dropbox Sign API accept JSON or form data?

By default — multipart/form-data or application/x-www-form-urlencoded. This is a common mistake: the developer sends JSON and gets a 400 error. Exception: some GET requests. Check the Content-Type before debugging.

How do I set up a webhook in Dropbox Sign?

In the Dropbox Sign UI: Settings -> API -> API Apps -> select or create an API App -> Callback URL. The webhook can be limited to specific events: signature_request_signed, signature_request_declined, signature_request_all_signed. For testing — use Test Mode: 1 in requests.

Does Dropbox Sign support multiple signers?

Yes. In the signers array you can specify multiple signers with order (signing sequence). Each receives their own email. The webhook signature_request_all_signed fires when everyone has signed — useful for bilateral signing (client + manager).

Does Dropbox Sign support embedded signing?

Yes. Via POST /embedded/sign_url/{signature_id} you get a temporary URL for iframe signing inside your application. Requires an API App with Embedded Signing domain configured.

Summary

• Dropbox Sign REST API: Basic Auth (API Key), multipart/form-data, templates with custom_fields
• Recommended approach: send_with_template — data from Kommo -> template, no PDF generation
• Webhook signature_request_signed -> update Kommo; response Hello API Event Received is mandatory
• Simpler to develop than OAuth-based e-signature platforms
• Typical development timeline — 1–2 weeks

If you use Dropbox Sign and want to automate document sending from Kommo — describe your templates and signing scheme. Exceltic.dev will review the custom_fields and propose an architecture.