Most CRM architecture problems I have seen did not start inside the CRM. They started at the edges, where a nightly script copies customer records into a billing system and nobody remembers who owns it. Choosing the integration pattern deliberately, per connection, saves you from that.

There are three patterns worth knowing. Each fits a different kind of question.

Pattern one: request-response APIs

The caller asks, the CRM answers. This is the right default when one system needs the current state of a record right now: a support tool looking up an account’s owner, or a quoting tool fetching a contact’s address.

Its strengths are simplicity and a clear failure mode. If the call fails, the caller knows immediately and can retry or show an error. Its weakness is coupling at runtime. If your support tool calls the CRM on every page load, a CRM slowdown becomes a support slowdown.

A common trap is using polling as a poor man’s notification. A job that asks “anything changed?” every minute multiplies your API traffic, burns through rate limits, and still leaves a delay. If you catch yourself writing a polling loop, look at the next pattern.

Pattern two: webhooks

The CRM tells the other system when something happens. A deal closes, a webhook fires, billing creates an account. This is push-based, so latency is low and there is no wasted polling.

In practice, webhooks need more care than they appear to:

• Receivers must respond quickly and do the real work asynchronously, otherwise the sender times out and retries.
• Deliveries can arrive twice or out of order, so handlers must be idempotent. Processing the same “deal closed” message twice should not create two billing accounts.
• Delivery is usually best-effort. You need a way to reconcile, for example a periodic check that compares counts or last-modified timestamps.

Check your CRM vendor’s current documentation for how retries, signing and ordering work. Those details differ and change.

Pattern three: an event stream or message queue

When several systems care about the same change, or when you need to absorb bursts, put a queue or stream between them. The CRM (or a small adapter) publishes a “contact updated” event once; billing, analytics and the marketing platform each consume it at their own pace.

The benefits are decoupling and buffering. A slow consumer does not slow the producer, and a consumer that was down for an hour can catch up afterward. The costs are operational: you now run, monitor and secure another component, and you must decide how long to keep events and how to handle messages that repeatedly fail.

Choosing between them

Situation	Better fit	Why
Need current data on demand	Request-response API	Simple, immediate, easy to debug
One downstream system needs to react quickly	Webhook	Low latency without polling
Many consumers, or bursty updates	Queue or event stream	Decoupling and buffering
Large one-time or periodic bulk load	Bulk/batch interface	Avoids hammering per-record endpoints
Consumer must never miss a change	Event stream plus periodic reconciliation	Replay and verification

Notice the last pair. Bulk loads and “never miss a change” requirements are where people force the wrong pattern. Loading a hundred thousand records through a per-record endpoint is slow and rude to the rate limiter; use the vendor’s bulk mechanism.

A short hypothetical

Suppose a small company connects its cloud CRM to a billing tool with a nightly script. Sales closes a deal at 9 a.m., but billing does not know until the next morning, so invoices go out a day late. Worse, when the script fails halfway one night, nobody notices for a week.

A better design: a webhook on “deal closed” calls a small receiver. The receiver drops the message onto a queue and returns immediately. A worker reads from the queue, creates the billing account using the CRM deal ID as an idempotency key, and records the result. A weekly reconciliation job compares closed deals against billing accounts and reports mismatches. Each piece is small, and each failure is visible.

Design habits that pay off

1. Pick one system of record per field. If both CRM and billing can edit a billing address, you will eventually overwrite one with the other. Decide who owns each field and make the other read-only.
2. Use stable identifiers. Store the CRM record ID in the downstream system and vice versa. Matching on email addresses breaks the first time someone changes theirs.
3. Put an integration user in the CRM. A dedicated service account with only the permissions it needs makes audit trails readable and limits damage if a credential leaks.
4. Log every integration event with a correlation ID. When someone asks why a record changed, you want to answer in minutes.
5. Plan for the CRM being unavailable. Decide in advance whether callers queue work, degrade gracefully, or fail loudly.

Frequently Asked Questions

Is a webhook better than an API call? They answer different needs. Use an API call when you need data on demand and a webhook when you want to be told about a change. Many integrations use both: a webhook says something changed, and the receiver calls the API to fetch the full record.

Do I need a message queue for a small CRM setup? Not always. With one or two downstream systems and modest volume, webhooks with idempotent handlers and a reconciliation job are often enough. Add a queue when you see bursts, multiple consumers, or lost messages.

How do I avoid duplicate records created by retries? Make handlers idempotent. Use the CRM record ID, or another stable key, as the identity of the operation, and check whether you have already processed it before creating anything.

How often should I reconcile systems? Often enough that a missed update is caught before it matters to a customer. For billing-related data that may be daily; for low-stakes enrichment, weekly is usually fine. Let the business cost of a missed change set the schedule.

Should integrations connect directly or go through middleware? Direct connections are fine for a few simple links. As the count grows, a shared integration layer gives you one place for retries, logging and credentials, at the price of another component to run.

Next Step

List every system that exchanges data with your CRM today. For each link, write down the pattern it uses, who owns the code, and what happens when it fails. Pick the one link with the worst answers and redesign that first.