A Full B2B Pipeline in Kommo via the API

A full B2B pipeline in Kommo via the API is built on three things that the standard pipeline lacks: custom fields and links for several stakeholders on a single deal, role synchronization through /api/v4/leads/complex, and transition automation via webhook instead of dragging cards by hand. The standard Kommo pipeline holds a linear cycle of “lead -> deal -> payment”. It cannot hold a complex B2B cycle with an economic buyer, a technical evangelist, and a lawyer - role data scatters across notes and gets lost as you scale.

In Exceltic.dev integration projects we keep seeing the same scenario: a team has outgrown the linear pipeline, 3-5 people on the client side are involved in a deal, and managers start running a “second CRM” in Notion or Google Sheets - because out of the box Kommo does not show which of the contacts is blocking the deal. The problem is not the platform. The problem is that B2B logic in Kommo has to be built out through the API, not configured with a mouse. Below is exactly how: which objects to use, how to synchronize roles, how to replace manual transitions with webhook automation, and how to assemble reporting that the native interface does not provide.

The pain is concrete: a head of sales cannot answer the board’s question “why has an $80k deal been stuck in the second stage for six weeks”, because the reason - an unanswered objection from a technical stakeholder - lives in a comment that no one parses. With a linear pipeline this is tolerable. With 40+ active B2B deals it is a blind spot that costs you the quarterly forecast.

What “a full B2B pipeline” means

A full B2B pipeline is one that reflects not the movement of a deal but the movement of a decision-making group of several people. A linear pipeline records a single status per deal. A B2B cycle requires recording the state of each role separately.

B2B pipeline: a pipeline model where a single deal has several contacts with different roles (economic buyer, technical evangelist, user, lawyer), and the transition between stages depends on the state of these roles rather than on a single flag.

Three things that distinguish a B2B pipeline from the standard one:

• Stages reflect the buying process, not the manager’s actions. Not “called - sent a quote”, but “DM qualification - technical validation - budget approval - legal review”.
• Several contacts and roles on a deal. Kommo lets you link several contacts to a deal, but out of the box it does not store their role in the purchase. Custom fields add that structure.
• Data is not lost as you scale. At 200 deals a year, information about roles, objections, and next steps must live in structured fields, not in free-text notes. Otherwise the context disappears when a deal is handed off between managers.

How the basic pipeline works and how stages differ from fields is covered in the piece on setting up a pipeline in Kommo - here we go further, down to the API level.

What the standard setup is missing

The standard Kommo setup does not store stakeholder roles and cannot do conditional transitions between stages based on the state of several contacts. These are the two main gaps for B2B.

What Kommo gives you out of the box:

• Multiple pipelines and statuses - managed through GET /api/v4/leads/pipelines and /statuses.
• Linking several contacts and one company to a deal.
• Custom fields of 14 types: text, numeric, select, multiselect, date, checkbox, url, textarea, and others.
• Digital Pipeline - a visual automation tool with triggers on stage change.

What is missing for B2B:

• A contact’s role in the deal. A contact is linked, but its role (DM / influencer / blocker) is not recorded structurally anywhere. The overview of Kommo features shows that the native data model is designed for a deal with a single primary contact.
• Conditional transitions based on role state. Digital Pipeline triggers on a stage change, but cannot “hold a deal back until the lawyer has confirmed”.
• Complex objects. There is no native “stakeholder” entity with its own fields - unlike HubSpot, where it is part of the data model. We covered the difference between the models in the article on the Kommo and HubSpot data model.

It is exactly these gaps that the API closes.

How to build out a B2B pipeline via the API

Building out a B2B pipeline via the API means adding a role structure with custom fields, synchronizing stakeholders through the complex endpoint, replacing manual transitions with webhook automation, and moving the data into reporting. Let’s break it down part by part.

Custom fields and workaround objects

Kommo does not let you create a new “stakeholder” entity, so roles are modeled in two ways. The first is custom fields on the contact: a select field “Role in the purchase” with values “DM / Influencer / User / Blocker”. It is created via POST /api/v4/contacts/custom_fields and filled in custom_fields_values with field_id and values.

The second approach, for complex scenarios, is a workaround object via lists / catalogs. You create a “Stakeholders” catalog with its own fields (role, approval status, date of last touch), and its items are linked to the deal. This gives the native deal a de facto child table - the equivalent of what the standard model lacks.

Workaround object: using a Kommo catalog as a child entity of a deal to store data for which the native model has no dedicated object.

For numeric analytical fields (objection weight, probability by role) the numeric type is used - it is convenient to aggregate later in reporting.

Synchronizing roles via the complex endpoint

When a lead arrives from a form or an outreach tool with several contacts at once, creating them one by one is a source of duplicates and race conditions. For this there is POST /api/v4/leads/complex: a single request creates the deal, links several contacts and the company to it, and sets custom fields on each.

An example payload - a deal with two stakeholders of different roles:

[
  {
    "name": "Внедрение для Acme Corp",
    "pipeline_id": 3104,
    "status_id": 142,
    "_embedded": {
      "contacts": [
        {
          "first_name": "Anna",
          "custom_fields_values": [
            { "field_id": 88011, "values": [{ "value": "ЛПР" }] }
          ]
        },
        {
          "first_name": "Mark",
          "custom_fields_values": [
            { "field_id": 88011, "values": [{ "value": "Технический евангелист" }] }
          ]
        }
      ],
      "companies": [{ "name": "Acme Corp" }]
    }
  }
]

The key to idempotency is deduplication by email or phone before the complex call, otherwise a repeated form submission will create a second contact. In practice, complex is preceded by GET /api/v4/contacts?query=email and a decision: create or update.

Automating transitions via webhook

Dragging deals between stages by hand in B2B is a source of desync: a manager forgets to move the card, the forecast lies. The replacement is a webhook from Digital Pipeline on a stage change that calls your service, checks the state of the roles, and decides whether to let the deal move on.

The limits that distinguish Digital Pipeline from general webhooks matter here (as of Q2 2026, per the Kommo documentation):

• The service waits for a response from your endpoint within 2 seconds. If you do not make it, or the response code is outside 100-299, the webhook is considered undelivered.
• In Digital Pipeline a webhook is sent once per event, with no retries. This is critical: all heavy logic must move to a background queue, and the endpoint must instantly return 200.
• General (non-DP) webhooks have softer logic - up to 4 retries within an hour.
• If more than 100 invalid responses come from an address within 5 minutes, delivery to it is paused for 5 minutes.
• Working with webhooks via the API is available on the Advanced, Pro, and Enterprise plans.

The correct architecture: the endpoint accepts the webhook, puts the task in a queue, and responds 200 in milliseconds. The worker checks the roles and, via PATCH /api/v4/leads/{id}, either moves the deal or creates a task for the manager “lawyer has not confirmed”.

Reporting on top of structured data

When roles and states live in custom fields rather than in notes, you get reporting that the native interface does not have: the distribution of deals by buying stage, the average time to pass legal review, the share of deals with no identified DM. The data is pulled via GET /api/v4/leads with filters and with=contacts, exported to BI, and closes the board’s question about the forecast.

A step-by-step plan

The order of implementing a B2B pipeline in Kommo via the API looks like this:

1. Describe the buying process, not the managers’ actions. Lock in the stages from DM qualification to signing. This defines the statuses of the pipeline.
2. Create custom role fields on the contact via POST /api/v4/contacts/custom_fields. At a minimum - a select “Role in the purchase”.
3. Decide whether you need a workaround object. If a deal consistently has 4+ stakeholders with their own lifecycle - set up a “Stakeholders” catalog.
4. Set up lead intake via /api/v4/leads/complex with contact deduplication by email or phone before creation.
5. Attach a webhook to the key stage changes in Digital Pipeline. The endpoint responds 200 instantly, the logic is in a background queue.
6. Implement the conditional transitions in the worker: check the state of the roles before the PATCH on the deal.
7. Export the data to BI via GET /api/v4/leads. Give the head of sales a dashboard by buying stage.

A real case study with numbers

In a typical Exceltic.dev project for a 22-person SaaS team on Kommo Pro, the pipeline held ~45 active B2B deals with an average deal size of around $35k and a 7-9 week cycle. Before the rework, stakeholder roles lived in notes, and the board’s forecast diverged from actuals by 30-40% quarter over quarter.

What we did: a select field “Role in the purchase” on the contact, a “Stakeholders” catalog with an “approval status” field, lead intake via complex with deduplication, and a webhook on the transition to the “Legal review” stage that blocked further movement until the lawyer’s status was “approved”.

The result over the quarter: the share of deals with an identified DM rose from 55% to 94%, and forecast accuracy improved - the divergence dropped from ~35% to ~12%. Managers stopped running a parallel spreadsheet in Sheets - about 4 hours a week per person went back into selling. The development effort was on the order of two weeks.

When it is worth it, and when it is time to move to HubSpot

Building out a B2B pipeline via the API in Kommo is worth it when the complexity is in the process, not in the data volume. If you have several stakeholders per deal, a non-linear cycle, and a need for conditional transitions - that is solvable on the Kommo API, and it costs less than a migration.

When to stay on Kommo and build out via the API:

• 20-150 active B2B deals, a cycle of up to 3 months.
• You need roles, conditional transitions, and decent reporting - but not a complex multi-object data model.
• The team values messengers and Kommo’s setup speed.

When it is time to look at HubSpot:

• You need a native multi-object model (Deals - Companies - Contacts - Tickets - Custom Objects) with relationships out of the box.
• Multi-touch attribution and complex revenue reporting at the platform level.
• The pipeline runs to tens of thousands of deals, where workaround objects via catalogs become tech debt.

How the data models of the two systems differ structurally and why this is the decisive factor in the choice - in the breakdown of Kommo vs HubSpot.

Frequently asked questions

Can you link several contacts with different roles to a deal in Kommo?

Yes. Kommo natively supports linking several contacts and one company to a deal - including in batch via POST /api/v4/leads/complex. But a contact’s role in the purchase is not stored natively: there is a “primary contact”, but not a “technical evangelist” or a “blocker”. The role is added with a custom select field on the contact via POST /api/v4/contacts/custom_fields. For complex scenarios with a stakeholder’s own lifecycle, a catalog is used as a workaround object. After that you can build filters and reporting by role via GET /api/v4/leads with with=contacts.

How does a Digital Pipeline webhook differ from an ordinary Kommo webhook?

There are two main differences. First, in Digital Pipeline a webhook is sent once per event, with no retries, whereas general webhooks have up to 4 retries within an hour. Second, your endpoint must respond within 2 seconds with a code of 100-299, otherwise the event is considered undelivered and is lost forever in DP. That is why heavy logic is moved to a background queue, and the endpoint responds 200 instantly. In addition, if more than 100 invalid responses come from an address within 5 minutes, Kommo pauses delivery for 5 minutes. Working with webhooks via the API is available on the Advanced, Pro, and Enterprise plans.

Do you need programming, or are Digital Pipeline and Salesbot enough?

For a linear pipeline, Digital Pipeline and Salesbot are enough, no code required. A full B2B pipeline with roles and conditional transitions requires code: the condition “do not let the deal move on until the lawyer has confirmed” cannot be expressed by native Digital Pipeline - it triggers on a stage change, but does not check the state of several contacts. That is why the key transitions are routed to your service via a webhook that checks the roles and moves the deal via PATCH /api/v4/leads/{id}. This is not full from-scratch development - in a typical project it is on the order of two weeks.

How do you avoid duplicate contacts when taking in leads via the API?

By deduplicating before writing. Kommo does not deduplicate automatically on creation via /api/v4/leads/complex - a repeated form submission will create a second contact. Before the complex call, a GET /api/v4/contacts?query= by email or phone is performed, and based on the result the system decides: create a new contact or update the existing one via PATCH. That is what idempotent lead intake is. Without it, the database fills up with duplicates within six months, and reporting by role stops being trustworthy.

Conclusion

A full B2B pipeline in Kommo via the API is realistic, if your complexity is in the process and not in tens of thousands of records.

• Stakeholder roles - custom fields on the contact or a catalog as a workaround object; lead intake - via /api/v4/leads/complex with deduplication.
• Conditional transitions - a webhook from Digital Pipeline to your service; remember the 2-second limit and single delivery with no retries.
• Reporting by buying stage - export via GET /api/v4/leads into BI, so the forecast matches actuals.
• If you need a native multi-object model and complex revenue reporting - that is a signal to look at HubSpot.

If you have hit the wall of the standard Kommo pipeline on a complex B2B cycle - describe your buying process and current deal volume to the Exceltic.dev team. We will work through the architecture of the fields and the webhook logic and estimate the scope of work.