Tilda form leads reach Kommo directly via webhook - no Zapier, no Make, no intermediate services. Tilda sends a POST request to your endpoint, the endpoint calls POST /api/v4/leads/complex in Kommo and creates a deal with a contact in a single request. UTM tags from the landing page go into custom deal fields. Deduplication runs by email and phone number.
From Exceltic.dev integration projects, about half of the companies that used Zapier for Tilda + Kommo ran into one of two scenarios: either Zapier started dropping leads when the task limit was exceeded, or the field mapping broke after a Tilda form update - and managers found out days later, when the leads had already gone cold. A custom webhook solves both scenarios: no intermediate service means none of its limitations.
This article covers the architecture of a direct integration: how Tilda sends data, how /leads/complex creates a deal with a contact in one request, and how to preserve UTM parameters in the deal card.
If you have already set up a pipeline in Kommo and connected forms through Zapier, this guide will show you why a direct webhook is cheaper and more reliable in production.
How Tilda sends form data
Tilda delivers form data via a webhook - an HTTP POST request to the URL you specify in settings. The path in the interface: “Site Settings -> Forms -> Webhook”. One URL is set for all forms on the site.
Webhook is a mechanism where the service pushes data to your endpoint at the moment an event occurs, without polling from your side.
The request format is application/x-www-form-urlencoded (not JSON). Form fields are passed as POST parameters. Standard fields have fixed names: Name, Email, Phone. Custom fields use the names you gave them in the block settings. Along with form fields, Tilda automatically adds two technical fields: tranid (unique submission ID) and formid (ID of the form block on the page).
Example payload when a form is submitted:
Name=Ivan+Petrov&Email=ivan%40company.com&Phone=%2B79991234567&tranid=123456789&formid=rec123456If you pass UTM tags through hidden form fields, they arrive as separate parameters: utm_source, utm_medium, utm_campaign.
Retry behavior: if your endpoint does not respond with 200 within 5 seconds, Tilda makes two retry requests at one-minute intervals. After the third failed attempt, the submission is considered undelivered. On first webhook connection Tilda sends a test request test=test - your endpoint must return 200 OK.
Idempotency: the tranid field is unique per submission. It is the key for deduplication on your endpoint side - if Tilda resent the request due to a network error, you can check whether you already created a deal with this tranid.
What gets implemented: a direct webhook with no middlemen
The integration setup looks like this: Tilda -> your middleware endpoint -> Kommo API. No Zapier, Make, or n8n in this chain.
Your endpoint receives a POST from Tilda, parses the fields, and calls POST https://{subdomain}.kommo.com/api/v4/leads/complex. This Kommo endpoint creates a deal and a contact in a single request - no need to first create a contact, get its ID, and then attach it to the deal.
Request body for /leads/complex:
[{
"name": "Tilda lead - Ivan Petrov",
"pipeline_id": 12345,
"status_id": 67890,
"custom_fields_values": [
{
"field_id": 111001,
"values": [{"value": "google"}]
},
{
"field_id": 111002,
"values": [{"value": "cpc"}]
}
],
"_embedded": {
"contacts": [{
"name": "Ivan Petrov",
"custom_fields_values": [
{
"field_id": 264911,
"values": [{"value": "+79991234567", "enum_code": "WORK"}]
},
{
"field_id": 264913,
"values": [{"value": "[email protected]", "enum_code": "WORK"}]
}
]
}]
}
}]The field_id values for phone and email in Kommo are not universal - you need to retrieve them via GET /api/v4/contacts/custom_fields for your account. pipeline_id and status_id are obtained similarly via GET /api/v4/leads/pipelines.
UTM parameters into custom fields. If Tilda’s form has hidden fields utm_source, utm_medium, utm_campaign, they arrive in the payload and can be written to custom deal fields via the same custom_fields_values. The deal card will then show the source: which campaign and channel brought the lead.
Deduplication by email and phone. When creating a contact via /leads/complex, Kommo checks whether a contact with the same phone number or email already exists. If one does, the new deal is attached to the existing contact instead of creating a duplicate. This behavior is built into the endpoint and requires no extra logic on your side.
Authentication with Kommo API uses OAuth 2.0. The access token is passed in the Authorization: Bearer {token} header. The token is valid for 24 hours and is refreshed via a refresh token.
Step-by-step integration guide
Here is how the implementation process looks from start to production launch.
Step 1. Configure hidden UTM fields in Tilda.
In the form block settings, add hidden fields: utm_source, utm_medium, utm_campaign, utm_term, utm_content. Tilda can automatically populate values from URL parameters into hidden fields - enable this option in the form settings.
Step 2. Build the middleware endpoint.
The endpoint receives a POST from Tilda, parses application/x-www-form-urlencoded, checks tranid for duplicates (cache or DB), builds the request body for Kommo, calls /leads/complex, and returns 200 OK no later than 4 seconds (with a margin before Tilda’s 5-second timeout).
Step 3. Connect the webhook in Tilda.
Site Settings -> Forms -> Webhook -> enter your endpoint URL. Tilda will send a test request test=test. The endpoint must return 200 OK for any request, including the test one.
Step 4. Map field_id values in Kommo. Retrieve current field IDs for your account:
GET /api/v4/contacts/custom_fields- contact fields (phone, email)GET /api/v4/leads/custom_fields- deal fields (UTM fields)GET /api/v4/leads/pipelines- pipeline and stage IDs
Step 5. Test on staging. Submit the form with test data and verify: did the deal appear in the correct pipeline, is the contact attached, are UTM values recorded, and does a duplicate contact not get created on resubmission.
Step 6. Monitor retry requests.
Add logging for tranid values and HTTP response statuses. If you see repeated tranid values, it means Tilda was retrying due to a slow endpoint response. Optimize response time: the main scenario should complete within 1-2 seconds.
Real-world case
A typical scenario from Exceltic.dev projects: a company with several Tilda landing pages and a sales pipeline in Kommo. Before the integration, managers checked incoming leads manually in email and copied data into the CRM. The average delay between a submitted form and a created deal was 2-4 hours during working hours and up to 12 hours outside of them.
After setting up the direct webhook:
- A deal in Kommo appears within 3-5 seconds of form submission
- UTM fields are filled automatically - the manager sees the lead source without asking questions
- Duplicate contacts are not created when the same client submits a form again - the new deal attaches to the existing contact
- Manual data entry is eliminated completely
In one project - a B2B services company with 3 active landing pages - the manager’s response time to a new lead dropped from several hours to 15-20 minutes in the first week after launch: the deal was already in the CRM with all fields filled in, all that was left was to call.
Zapier in similar scenarios added a 5-15 minute delay (polling interval on the base plan) plus regular failures when the task limit ran out. A direct webhook operates in real time and is not subject to a third service’s plan limits.
Who this integration is right for
The solution is relevant for companies on Kommo where Tilda is the main or one of the main inbound lead sources. Most commonly these are companies with 15-50 employees that have a dedicated sales team and several landing pages for different products or campaigns.
If you already use Kommo as the foundation of your pipeline and want to understand what other platform features are not being used, read the full Kommo CRM overview.
A direct webhook is especially useful in three situations:
- Zapier or Make are already hitting task limits or costing more than you would like
- UTM parameter tracking in Kommo is required - native integrations do not support this at the needed depth
- Contact deduplication needs to be under your control: multiple forms, one client can submit several
A similar approach - a direct webhook with no middlemen - is used in other Kommo integrations as well: for example, in Kommo + Stripe integration, where payment events are written to the deal card via Stripe webhook.
If your stack extends beyond Kommo and includes paid traffic channels, it is worth looking at how UTM data from the CRM maps back to real deal cost - that is what Prooflytics solves for teams running Kommo alongside multiple advertising channels.
Frequently asked questions
Is Zapier or Make required for Tilda to Kommo integration?
No. Tilda supports sending form data directly to any URL via webhook (POST request). Kommo accepts data via REST API. All you need is a middleware endpoint - a small script or serverless function that receives the request from Tilda and calls the Kommo API. No paid automation services are needed in this chain.
What happens if my endpoint is unavailable when a form is submitted?
Tilda will make two retry requests at one-minute intervals. If all three attempts fail, the submission will be lost. To avoid this: use a reliable host with uptime above 99.9%, set up endpoint monitoring, and add error alerts. For critical forms you can add a fallback channel - for example, mirror the data to a table or queue if the Kommo request fails.
How do I pass UTM tags from the landing page into the Kommo deal card?
Add hidden fields named utm_source, utm_medium, and utm_campaign to the Tilda form. Enable auto-population of values from URL parameters in the form settings - Tilda supports this out of the box. The hidden fields arrive in the webhook payload along with the rest of the form data. On the middleware side, write them into custom deal fields via custom_fields_values in the request to /leads/complex.
How do I avoid duplicates if someone submits the form twice?
When creating a contact via /leads/complex, Kommo checks the database for a match by email and phone. If a contact with those details already exists, the new deal is attached to the existing contact rather than creating a second contact. Additionally, use the tranid field from Tilda as an idempotency key on the endpoint side: store processed tranid values and ignore repeat requests with the same ID.
What form data from Tilda can be passed to Kommo?
Any form fields: name, email, phone, text fields, dropdowns, checkboxes. Plus hidden fields - UTM tags, page IDs, any other data you want to pass. There are no technical limits on which fields can be included - everything Tilda sends in the webhook payload is available in the middleware and can be written to standard or custom Kommo fields.
Summary
A direct Tilda -> Kommo webhook is more reliable and cheaper than any automation service in between:
- Leads reach the CRM within seconds, not minutes
- UTM data is saved in deal fields without manual entry
- Contact deduplication works through Kommo’s built-in logic
- No dependency on Zapier or Make plan limits
If you already have Tilda and Kommo and want to set up direct lead delivery - describe your form and current stack to the Exceltic.dev team. We will work out the architecture and propose a solution for your traffic volume and field set.