Every CRM implementation eventually reaches the same meeting: the finance system, the marketing platform, the support desk, and the data warehouse all need to talk to the CRM, and someone has to decide how. The options sound interchangeable in a slide deck. They are not, and the choice tends to outlive the project that made it.

There are three broad approaches. You can use a prebuilt connector from the CRM vendor or a marketplace, run the data through an integration platform (often called middleware or iPaaS), or write custom code against the CRM’s APIs. Each fits certain situations.

Native and Marketplace Connectors

A prebuilt connector is the fastest way to a working integration. Someone has already decided how a contact in one system maps to a contact in another, and the vendor maintains it as APIs change.

The trade-off is flexibility. Connectors tend to cover the common case and handle unusual requirements awkwardly. Typical limitations include fixed field mappings, limited control over sync direction and frequency, and little visibility into why a record failed. Before relying on one, look closely at what it actually syncs, how it deals with conflicts, and what happens to records that fail. Check the vendor’s current documentation, because capabilities differ widely between connectors with similar names.

Connectors suit standard pairings with modest requirements, such as syncing contacts to an email tool.

Integration Platforms

Middleware sits between systems and gives you a place to build, monitor, and change flows without writing everything from scratch. You get visual or configuration-based mapping, scheduling, retries, and usually logging.

This is a good fit when you have several systems to connect, when data needs transforming along the way, or when you want one place to see what is running. The cost is another subscription, another platform to learn and secure, and another dependency. If your integration platform goes down or its owner leaves, many processes stop at once. Someone must own it.

Custom API Integration

Custom code gives you total control: exact logic, specific error handling, and behaviour that matches your process. It also means you own everything. Authentication changes, API deprecations, rate limits, and retries become your problem. Cloud vendors evolve their APIs over time, so a custom integration needs ongoing maintenance, not a one-time build.

Custom work earns its place when the logic is truly specific to your business, when volumes are high enough that platform pricing or limits bite, or when no suitable connector exists. It rarely earns its place for plain contact syncing.

Comparing the Approaches

Factor	Native Connector	Integration Platform	Custom API
Time to first result	Shortest	Moderate	Longest
Flexibility	Limited	Good	Complete
Visibility into failures	Often basic	Usually good	What you build
Ongoing maintenance	Vendor-led	Shared	Entirely yours
Best for	Standard pairings	Many systems, transformations	Unique logic or high volume

Questions That Decide It

Rather than asking which approach is best, ask these about each integration:

1. Which system is the source of truth for each field, and does data flow one way or both?
2. How fresh does the data need to be: real time, hourly, nightly?
3. What happens when a record fails, and who finds out?
4. How many records move, and how often, relative to API limits?
5. Who will maintain this in two years?

Bi-directional sync deserves special caution. Two systems both allowed to edit the same field is the root of most sync conflict headaches. Where possible, assign each field a single owner.

Design for Failure From the Start

Integrations fail. Credentials expire, a field gets renamed, a rate limit trips, the other system has an outage. Plan for it: retries with sensible backoff, a queue or log of failed records, alerts that reach a human, and a documented way to reprocess. An integration without error visibility is not finished, it is just quiet.

Use dedicated integration accounts with only the permissions required, never a personal login, and store secrets in a proper secrets manager. When a person leaves and their account is disabled, you do not want your invoicing flow to die with it.

A Hypothetical Example

A team needs customer records shared between the CRM and a billing system. A marketplace connector exists, but it only syncs on a fixed schedule and cannot handle their custom account hierarchy. They put an integration platform in the middle, map the hierarchy in one transformation step, and send failed records to a review queue that the finance operations lead checks each morning.

For a separate marketing-list sync, they simply use the vendor’s connector, because the requirements are plain. Mixing approaches by need is entirely normal.

Document Every Integration

Keep a simple register: what connects to what, direction, frequency, owner, credentials location, and how to restart it. It is also the first thing you need in an audit or when planning a future migration.

Frequently Asked Questions

Is middleware always better than direct connectors? No. For a simple, well-supported pairing, a connector is less to manage. Middleware pays off as the number and complexity of integrations grows.

How do we avoid hitting API limits? Batch where possible, avoid polling when events or webhooks are available, and schedule heavy jobs off-peak. Check your platform’s current limits in its documentation.

Should integrations be real time? Only where the business needs it. Near-real-time adds complexity and cost. Many processes are fine with hourly or nightly updates.

Who should own integrations: IT or the business? Technical operation usually sits with IT or a platform team, while the business owns the rules about what data should flow and why.

What should we test before go-live? Volume, failures, duplicates, and permission changes, not only the happy path with a handful of clean records.

Next Step

Take your integration list, answer the five questions for each, and pick the lightest approach that meets the answers. Then name an owner for every one.