Zoho CRM to Kafka: How to Move Your Data

Moving Zoho CRM onto Kafka publishes commercial records where several systems can react to them. Fulfilment, billing, support tooling and analytics all want to know when a deal closes, and pointing four services at one CRM API means four integrations competing for the same allowance.

This guide covers the managed path with Airbyte. Two things shape the build: your stream list is discovered rather than fixed, which complicates creating topics in advance, and business users can change the shape of your messages without telling anybody.

Zoho CRM to Kafka at a glance:

Why move data from Zoho CRM to Kafka?

Two situations account for most of these pipelines.

The first is fan-out to systems that each do something different with a record. Publishing once means one well-behaved caller against an API metered by credits, rather than several teams independently drawing on the same daily allowance.

The second is feeding an event-driven platform where Kafka is already the backbone. If a single team wants to analyse this data rather than react to it, Zoho CRM to BigQuery is simpler to build and far easier to query afterwards.

What do you need before you start?

Four things, and the last one cannot be finalised until the first three are right:

OAuth credentials with module and field metadata scopes. A client identifier, secret and refresh token from a Zoho API client. The Zoho CRM source documentation covers the setup and the metadata APIs discovery depends on.

Your region, environment and edition. These three look like boilerplate and decide which modules you can reach and how much you may pull in a day, so set them deliberately rather than accepting defaults.

A cluster where you can create topics on demand. The destination writes to topics that already exist, and you will not know exactly which ones you need until discovery has run.

Consumers written to tolerate unfamiliar fields. Because the people who administer your CRM can change what a record contains, and they will not think of it as a schema change.

If your cluster restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list before you begin.

How do you build a Zoho CRM to Kafka pipeline in Airbyte?

Step 1: Run discovery before you create any topics

Configure the source and let it discover your streams first, because the list comes from your own Zoho metadata rather than from a catalogue somebody else would recognise. Creating topics from an assumed set of module names wastes an afternoon on a heavily customised instance, and discovery takes ten to thirty seconds. Check the result against the modules you expected before going further.

Step 2: Configure the Zoho CRM source

Click Sources in the left navigation, then New Source, and select Zoho CRM, following adding a source. Supply the OAuth credentials, region, environment and edition, plus a start date. If discovery takes much longer than half a minute, or returns streams you do not recognise, one of those three fields is usually the reason.

Step 3: Configure the Kafka destination

Click Destinations, then New Destination, and select Kafka, following adding a destination. Supply the bootstrap servers, security protocol and topic configuration, creating a topic per module you intend to publish. Messages are JSON wrapping each record with its identifier and stream name, so consumers read through an envelope.

Step 4: Create the connection and schedule against credits

Click Connections, then New connection, select your modules and a sync mode. Both full refresh and incremental are supported, and incremental is right for a bus. Set the frequency against your daily credit allowance rather than against how fresh anybody would like it.

Then tell your consumer teams what to expect, since the message shape is not as fixed as it looks.

Why can you not plan your topics in advance?

Because the connector builds its streams from your Zoho metadata rather than from a fixed list. The available streams are the modules for which module and field metadata can be retrieved, which means your catalogue reflects how your organisation configured its CRM, including custom modules somebody in sales operations created two years ago.

That is a strength for a customised instance and an awkwardness for this destination specifically, because Kafka wants its topics to exist before anything writes to them. The ordinary approach of designing topics from a known schema does not apply, and the practical sequence is to discover first, review what came back, then create topics for the modules you actually intend to publish.

Check the discovered list against what you expected rather than assuming it is complete. There is a reported issue in which users on a sandbox environment saw an unexpected stream list while the same credentials returned the right modules when called directly, so a catalogue missing something obvious is worth investigating rather than accepting. Your environment and edition settings are the first place to look.

What happens when somebody adds a field in Zoho?

Your messages change shape, and nobody involved thinks of it as a schema change. Adding a custom field to a module is an ordinary Tuesday task for a CRM administrator, and because discovery reads field metadata, that field becomes part of the stream once the schema is refreshed. The producer changed and no version was bumped.

Consumers therefore need to tolerate fields they have never seen rather than validating strictly against a shape they remember. That is good practice generally and essential here, because the rate of change is set by however often your sales operations team improves something, which is not a rate anybody engineering the consumer controls.

Two related cautions. Anything outside the connector's type mapping arrives as a string, so a consumer expecting a number should parse defensively rather than trust the field. And a custom module that appears in discovery has no topic waiting for it, so new things in Zoho need a deliberate decision to publish rather than arriving automatically. Tell the CRM administrators that their changes now reach other systems.

Frequently asked questions

Why does my stream list differ from the documentation?

Streams are built dynamically from your own Zoho metadata, so the catalogue reflects your configuration including custom modules rather than a fixed set.

Main modules are missing from discovery.

Check your environment and edition first, since those shape what is reachable. There is also a reported issue affecting sandbox environments, so compare against calling the API directly.

Will new custom fields reach my consumers?

Once the schema is refreshed, yes, so consumers should ignore unfamiliar fields rather than failing on them. A new custom module needs a topic before it can be published.

Why is a numeric field arriving as text?

Anything outside the connector's type mapping becomes a string, so consumers should parse rather than assume the type they expected.

Can I do this without writing code?

The pipeline, yes. The consumers are yours, and making them tolerant of new fields is the part that keeps this working as your CRM evolves.

Get your Zoho CRM data into Kafka

Discover your streams before creating topics, because the list comes from your own metadata and assuming a standard set of modules wastes time. Set region, environment and edition deliberately, and check the discovered catalogue against what you expected. Then write consumers that tolerate unfamiliar fields and parse defensively, since a CRM administrator adding a field is a producer change nobody will announce.

Airbyte's connector catalog includes 600+ pre-built connectors, so commercial records can reach every system that reacts to them. For another CRM onto the same bus, see Salesforce to Kafka, and for the same source into a lakehouse, Zoho CRM to Databricks.

Start syncing now →