What Kala CRM exposes for integration according to its own published release notes: a lead-creation REST API, a Zapier connection, outbound calls, and the gaps.
Key takeaways
- The three channels documented in Kala's own release notes are RESTful lead intake, a Zapier connection, and outbound calls fired from automations.
- The Zapier connection is documented with a specific capability: search an enquiry by phone, then update it or add a new one. That is exactly the capability that prevents duplicates.
- Kala publishes ready-made connectors for WordPress, Shopify, Konimbo and Admonis, plus WhatsApp messaging and a phone system connection.
- There is no public developer portal listing endpoints, schemas and an authentication method. What exists is release notes and product pages.
- So the scope of a Kala project is settled in a conversation with the vendor, not by reading a specification. Planning that assumes otherwise will miss its date.
Kala CRM exposes three integration channels that the company documented in its own release notes: a RESTful interface for creating leads from external sources, a Zapier connection that can find and update an enquiry by phone number, and an automation engine that can send outbound API calls to other systems, including PUT. A full developer portal is not published.
What Kala CRM covers, and why that matters for integration
Kala CRM is an Israeli business management system covering a wide range inside a single product: enquiry and customer management, orders and sales processes, invoice issuing, card processing, recurring retainer billing through a Masav standing-order interface, projects and tasks, a calendar, forms and reports.
That breadth is precisely what matters for integration. In a system that covers both sales and billing, the first question is not "how do we connect" but "what actually needs to leave the system at all". If billing already happens inside Kala, there is no reason to duplicate it into an external invoicing product, and half the integration you planned disappears. In a small business that is the difference between a two-week project and a two-month one.
The second question is ownership scope. A system holding the customer list, the orders and the billing also holds your ability to replace it. That is a separate consideration, discussed in custom CRM versus off-the-shelf CRM.
Does Kala CRM have a public API?
There is an interface, but not public documentation in the sense a developer expects. What appears in the company's own publications:
- An April 2018 update states support for a RESTful API for creating leads from external sources. That is inbound enquiry intake.
- A 2019 update for version 5.4 states an improvement to the Zapier integration, including searching and updating or adding an enquiry by phone number.
- A June 2019 update states that automations can issue PUT API calls to update data in external systems.
What I did not find: an endpoint list, field schemas, an authentication method, rate limits, or a dedicated developer page. I am not claiming the vendor has none. I am saying they are not published, and planning that leans on them is a bet. The step-by-step version is in how to build a custom CRM.
The practical difference is directional. Inbound lead creation is the best-documented capability and also the most commonly used in practice. Pulling the customer database out, by contrast, is not documented in anything I found. For realistic build tiers and what moves a project between them, see how much a custom CRM costs.
Two directions of automation, and why not to conflate them
| Direction | Who initiates | Typical example | What Kala documents |
|---|---|---|---|
| Inbound | External system | A website form creates a new enquiry | RESTful lead-creation API, WordPress and store connectors |
| Outbound push | Kala | A status change triggers an update elsewhere | Outbound calls from automations, including PUT |
| Two-way via a broker | Zapier | Search by phone, then update or add | Zapier connection documented in release notes |
| Outbound pull | Your system | A nightly sync of all customers to BI | I found no public documentation |
That last row is what sinks projects. A team assuming that an intake API implies an extraction API finds out otherwise after it has already committed to a date. If you need the data outside - for BI, for a report, for a backup - that is the first thing to establish, not the last.
How to scope an integration against a system with no published specification
- Write the scenarios as business sentences before writing a line of code: "an enquiry from the site arrives with a source and a tag", "an approved order creates a task".
- Mark each scenario with its direction from the table above. Every scenario in the last row is an open risk.
- Ask the vendor in writing, per scenario, for the path, the authentication method and a sample request and response. A general answer is not a specification.
- Run one real call against a test account before you price the rest. A call that worked is worth more than any promise.
- Define what happens when a call fails: a retry queue, an alert, and a place where the enquiry does not vanish.
Step four is the one teams skip, and it is the only one that converts a promise into a fact. Step five decides whether the integration survives six months: a lead lost to a timeout and stored nowhere is a customer lost silently.
What actually breaks in connections like these
- Duplicates of the same customer. With no search by phone or email before creation, every resubmitted form creates another enquiry. The Zapier search-by-phone capability exists for exactly this.
- Phone number formatting. 0526856459, 972526856459 and +972-52-685-6459 are one number to a human and three different keys to a system. Normalise before the search, not after.
- The enquiry source disappears. A lead arriving through an API with no source field lands in the report as "unknown", and channels can no longer be compared.
- An automation running on data not yet written. A trigger firing immediately on enquiry creation can execute before the form fields are stored.
- A loop between two systems. An update in Kala pushes to an external system, which pushes back, which fires the trigger again.
- Dependence on one employee's account. A key or Zapier connection created under a user who has left dies on the day that user is disabled.
What should you establish with the vendor before committing?
- Whether extraction of records outbound exists at all, and not only intake inbound.
- How authentication works: a static key, a refreshing token, or a dedicated user, and who issues it.
- Whether there is a webhook or a change trigger, or whether polling is the only route.
- What the rate limit is, and what happens when you exceed it.
- Whether a separate test environment exists, or whether every experiment touches live data.
- Who on the vendor's side owns the connection, and what the response time is when it breaks.
Related: connecting CRM and ERP in a small business, the WhatsApp Cloud API guide for Israel.
Sources
Frequently asked questions
What exactly can you do with the Kala CRM API?
According to the release notes the company published, the interface supports creating leads from external sources, and the internal automation engine can send outbound calls to other systems. Extracting existing records outbound is not documented in the public publications, so it has to be established directly with the vendor before scoping.
Does Kala CRM connect to Zapier?
Yes. A 2019 version update describes an improvement to the Zapier integration, including the ability to search an enquiry by phone number and then update it or add a new one. That is precisely the capability that avoids creating duplicates when the same customer submits a form more than once.
Which store platforms does Kala connect to directly?
According to the company's site there are connections to WordPress sites via a plugin that transfers order details and form enquiries, and to sites built on Shopify, on Konimbo, and to the Admonis order management system. Anything beyond those is presented as a custom integration rather than a ready connector.
How do you prevent duplicates when feeding leads from several sources?
Pick one identity key, usually a phone number normalised to a single format, and search for it before every create. If a record is found, update it and add an interaction; if not, create a new one. The normalisation has to happen on the sending side, before the search runs.
Keep reading
Related service
Custom CRM
A CRM built around your pipeline, connected to the tools you already use.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.