Kommo + Apollo.io: Syncing Outbound Prospecting Leads to CRM Without Zapier
The Kommo + Apollo.io lead sync integration is built on a direct API connection: a webhook from Apollo passes a contact to Kommo the moment it is added to a sequence, without Zapier and without manual transfer. Deduplication by email and Apollo ID prevents duplicate creation even when multiple SDRs work in parallel. There is a reverse flow too - when a deal closes in Kommo, the contact’s status in Apollo updates automatically.
SDR teams that run prospecting in Apollo.io and manage deals in Kommo lose 2 to 6 hours a day to manual data transfer. A contact replied to an email - someone has to find them in Apollo, copy the data, create a deal in the CRM. With several people working over overlapping lists - also sort out duplicates. Custom integrations for Kommo solve this at the API level, without intermediaries and without manual steps.
Why Apollo.io Does Not Integrate with Kommo Natively
As of Q2 2026, Apollo.io’s list of native CRM integrations includes HubSpot, Salesforce, Pipedrive, and Outreach. Kommo is not there. This is an Apollo architectural decision: the company focuses on the enterprise segment and popular Western CRMs.
Available options without custom development:
- CSV export/import. Works up to 20-30 contacts per day. Beyond that - daily manual routine.
- Zapier or Albato. Polling model: data from Apollo is delivered with a 5-15 minute delay depending on the plan. If the intermediary fails - data is lost without notification. At a volume of 50+ leads per day, the cost of Zapier exceeds the cost of a custom solution within 3-4 months.
Polling integration - a model where an intermediary service periodically queries the data source on a schedule rather than reacting to events in real time. The opposite is a webhook architecture, which is event-driven and has no delay.
For teams of 5+ SDRs with a volume of 50+ contacts per day, none of the above options delivers acceptable speed and reliability.
Kommo + Apollo.io Integration: Lead Sync Architecture
The integration consists of two data transfer channels - from Apollo to Kommo and back.
Channel 1: Apollo.io -> Kommo
Apollo.io supports webhook notifications for key contact events. Three events are used for lead sync:
contact_added_to_sequence- contact added to an outbound sequencereply_detected- contact replied to a sequence emailcontact_stage_changed- contact stage changed in Apollo
Each event sends a POST request to the middleware with the full contact payload. The middleware checks for duplicates and creates or updates the record in Kommo.
Channel 2: Kommo -> Apollo.io
The Kommo webhook fires when a deal status changes. When a deal moves to “Won” or “Lost,” the middleware sends a PATCH to the Apollo API and updates the contact stage - the SDR sees the current status without needing to switch to the CRM.
Technical Details
Apollo.io API v1 (Apollo documentation) works over REST, authentication via x-api-key header. Key endpoints for integration:
GET https://api.apollo.io/v1/contacts/search - search contact by email
POST https://api.apollo.io/v1/contacts - create contact
POST https://api.apollo.io/v1/people/enrich - enrich person dataKommo API v4 (Kommo documentation) works via OAuth 2.0. Key endpoints:
GET /api/v4/contacts?query={email} - search for duplicate by email
POST /api/v4/contacts - create contact
POST /api/v4/leads - create deal
PATCH /api/v4/contacts/{id} - update existing contactApollo -> Kommo field mapping:
| Apollo field | Kommo field |
|---|---|
| first_name + last_name | Contact name |
| organization_name | Company name |
| title | Custom field “Job Title” |
| phone_numbers[0].raw_number | Phone |
| linkedin_url | Custom field “LinkedIn” |
| contact_stage_id | Custom field “Apollo Stage” |
| id | Custom field “Apollo ID” |
The Apollo ID field is the idempotency key. Before creating a record, the middleware checks: does Kommo have a contact with this Apollo ID in the custom field? If yes - update, do not create a duplicate. This works even when two SDRs simultaneously add the same contact to different sequences.
How Lead Sync Works Step by Step
- An SDR adds a prospect to an Apollo.io sequence
- Apollo sends the
contact_added_to_sequencewebhook to the middleware within 1-3 seconds - The middleware extracts the email from the payload, makes a
GET /api/v4/contacts?query={email}request in Kommo - If the contact is not found - creates a new contact (
POST /api/v4/contacts) and a deal in the target pipeline (POST /api/v4/leads) - If the contact is found - updates the existing record (
PATCH), adds a note “Added to Apollo sequence: {sequence_name}” - Apollo ID is written to the Kommo custom field for all subsequent updates
When the prospect replies to an email (reply_detected event):
- The middleware receives the webhook, finds the deal in Kommo by Apollo ID
- Moves the deal to the next pipeline stage - for example, from “Outbound” to “Qualification”
- Adds a note with the date and the fact of the reply (or the email body, if Apollo passes it)
The pipeline structure and stages in Kommo must be agreed before the integration launches: which stage corresponds to each Apollo event - that is a design decision, not a technical detail.
Real Case: SDR Team of 8
A company - international B2B SaaS, sales team in Europe. Before integration: 8 SDRs, each working in Apollo with their own list, leads created in Kommo manually at the end of the workday. Average delay between a prospect’s reply and the deal appearing in the CRM - 4-6 hours. Managers were seeing “hot” contacts with a lag.
Results after launching the custom integration (first 30 days):
- Delay in passing a contact from Apollo to Kommo - 30-60 seconds
- Duplicates during parallel SDR work - 0 (deduplication by email + Apollo ID)
- Manual data transfer completely eliminated
- Unique contacts passed in the month - 1,400
Development and launch: 3 weeks. Of these - 1 week on pipeline audit and field mapping, 2 weeks on middleware development and testing. The same event-driven architecture is used in the Kommo + ActiveCampaign integration - webhook model instead of polling for contact sync there as well.
Who This Is For
The integration is relevant when all three conditions are met simultaneously:
- A dedicated SDR team of 3+ people working in Apollo.io and running outbound prospecting
- Kommo is the main CRM for deals and client communication
- The volume of new contacts from Apollo exceeds 30-50 per day (at lower volumes a manual process or daily CSV export is sufficient)
Not suitable if Apollo.io is used only for data enrichment (People Enrichment API) and not for launching sequences. That scenario requires a different architecture - via the enrich API, not event webhooks.
Similar to the custom Kommo + ClickUp integration without Zapier, a custom solution gives full control: what exactly creates a record in the CRM, which fields are passed, what happens on a network error.
Frequently Asked Questions
Is there a ready-made Kommo Apollo.io lead sync integration without development?
As of Q2 2026 - no. Apollo.io does not support Kommo in its list of native CRM integrations. Albato and Zapier allow setting up basic data transfer, but work on a polling model with a 5-15 minute delay. If the intermediary fails, data is lost without notification. For teams with a volume of 30+ leads per day, a polling integration creates more problems than it solves: duplicates, missed contacts, opaque errors.
How does deduplication work when syncing Apollo and Kommo?
The middleware checks two keys: email and Apollo ID. On an incoming webhook, it first makes a GET /api/v4/contacts?query={email} request in Kommo. If found - the contact is updated, not recreated. Apollo ID is saved in the Kommo custom field and serves as the key for all subsequent updates to that contact. When two SDRs work with the same prospect simultaneously - both webhooks are processed correctly: the first creates the record, the second updates it.
Which Apollo.io events can be used as Kommo triggers?
Three events are used as standard: contact_added_to_sequence (added to sequence), reply_detected (email reply), contact_stage_changed (stage change in Apollo). If needed, email_opened, email_clicked, and meeting_booked can also be connected - depending on which prospect actions should change the deal status in Kommo.
What to do if the Apollo API returns an error under high load?
The Apollo.io API has rate limits: on the basic plan - around 10 requests per minute for search and enrichment endpoints. Under peak load the middleware implements exponential backoff: first retry after 2 seconds, second after 4, third after 8. If all attempts are exhausted - the event is placed in a queue for later processing. Data is not lost, only delayed.
How long does developing the Kommo + Apollo.io integration take?
In a typical project - 2-3 weeks. Week one: audit of the Kommo pipeline, Apollo sequence structure, agreeing on field mapping and stage transition logic. Week two: middleware development, webhook setup on both sides, testing with real data. Week three (if needed): load testing and production launch with monitoring of the first 500-1,000 contacts.
If the SDR team works in Apollo.io and the pipeline is managed in Kommo - describe the task to the Exceltic.dev team: current daily contact volume, team size, what was unsatisfactory about the current process. We will design the sync architecture and estimate the scope of work.