A working guide to connecting your CRM to the rest of your stack, covering authentication, webhooks versus polling, rate limits, and the failure modes that take integrations down.
Most CRM integrations fail for the same handful of reasons: nobody checked what happens when the API is down, nobody handled a duplicate record, and nobody read the rate limit until it started returning errors in production. This is the checklist we run through on every integration project, before a single line of code gets written.
Before you open either app's API documentation, draw the direction the data moves. A new lead in your CRM that needs to appear in your email tool is a one-way flow. A support ticket that updates a customer record, which then needs to show the latest ticket status back inside the CRM, is two-way, and two-way syncs are where most integrations get into trouble: each side can overwrite a change the other side already made.
If the flow is two-way, decide now which system owns each field. If your CRM owns the customer's email address and your support desk owns ticket status, write that down before you build anything. Without an owner, both systems eventually disagree about which record is correct.
Most CRMs offer two ways in. An API key is a single long string of text tied to your account that doesn't expire on its own. It's simple to set up and simple to leak, since anyone who sees it has the same access you do until you revoke it.
OAuth asks a user to log in and grant specific permissions, then issues a token that expires and refreshes automatically. It takes longer to set up but limits what the integration can see and do, and it survives a password change without breaking. For anything touching customer data, we default to OAuth when the CRM supports it.
A webhook is the CRM calling your system the moment something changes: a new deal, a stage change, a note added. It's close to instant and uses no resources while nothing is happening.
Polling is your system asking the CRM "anything new?" on a timer, every five minutes or every hour. It's slower and uses more API calls, but it works with CRMs that don't offer a webhook for the event you care about, and it catches anything a missed or failed webhook delivery would otherwise drop.
A reliable integration often uses both: webhooks for speed, and a polling job once a day that reconciles anything the webhooks missed.
Every CRM API caps how many requests you can make in a given window, often somewhere between a few hundred and a few thousand per minute depending on your plan. Hit that cap and the API starts rejecting calls, usually with a 429 status code.
The failure we see most: an integration that works fine in testing with a handful of records, then falls over in production once a real customer list runs through it, because nobody built in a delay between batches or checked the documented limit first. Read the limit before you build the loop that calls the API, not after it starts failing.
Networks drop requests. APIs time out. The question isn't whether a call will fail, it's what your integration does next.
Inheriting a broken integration? The fastest diagnosis is almost always the error log, if one exists. If nothing was logging failures, that's the first thing to fix, before touching the integration logic itself.
Use webhooks when the CRM supports them and you need updates within seconds, such as triggering a welcome email when a deal closes. Use polling when the CRM has no webhook for that event, when you need to catch changes you might have missed, or when checking every few minutes is fast enough.
Retrying a failed request without checking whether it already partially succeeded. A payment record gets created twice, a welcome email goes out twice, because the integration retried a call that had gone through but failed to confirm. Idempotency keys fix this.
For a simple one-field sync through Make or n8n's built-in modules, no. Once the integration needs custom logic, handles its own retries, or moves sensitive data like payment details, you want someone who understands API authentication and failure handling, not only the visual builder.
Tell us which tools and what data needs to move between them. We'll map the integration, flag the risks, and build it to survive the failure cases above.
Start a Project →