APIs and webhooks: why your tools don't talk

The reason your CRM doesn't know about the payment is almost never that an integration is impossible. It's that nobody decided which system is the source of truth, and nobody chose how the data would travel. Those two decisions are most of the work. The connection itself is comparatively boring — but you still have to understand what you're buying, because the failure modes are specific and they surface in month three, not week one.

Why your tools don't already talk

Most business software is built to be the center of your world. Your CRM assumes it holds the customer record; your accounting package assumes it holds the customer record; your scheduling tool assumes the same. All three are internally consistent and none of them agrees with the others.

So the first question isn't technical. It's: when these two systems disagree about a customer's email address, which one wins? Answer that before you write or buy anything, or the integration will faithfully propagate the disagreement in both directions until someone notices the data is garbage.

The second question is which events matter — rarely all of them. A useful integration moves three or four, not the entire object model. Mapping the process first tells you which three.

API vs webhook, side by side

Most sound integrations use both: webhooks for the fast path, and a scheduled API sweep that reconciles whatever the webhooks missed. If you only build one, build the sweep — it's slower, but it self-heals.

Rate limits are a real constraint, and they're published

A rate limit is the maximum number of requests a vendor will accept in a window. Cross it and requests start failing, usually with an HTTP 429. It catches people out because it never shows up in testing on ten records — it shows up during the first full migration, on forty thousand. The numbers are public:

Two consequences. A daily cap means a large one-time import may need to spread across days, or run through a bulk endpoint. And when several tools share one connection — automation platform, reporting tool and warehouse sync on the same account — they share one budget, so the tool that breaks is rarely the one that caused the problem.

Webhooks fail in ways polling doesn't

Webhooks are a delivery attempt, not a delivery guarantee. Stripe's documentation is unusually direct about this, and worth reading even if you don't use Stripe, because the behavior is typical of the category.

Stripe attempts delivery for up to three days in live mode with exponential backoff. It states that endpoints may receive the same event more than once and recommends logging processed event IDs to discard repeats. It says explicitly that it does not guarantee events arrive in the order they were generated. Its libraries default to a five-minute timestamp tolerance on signed webhooks, to blunt replay attacks.

So any webhook consumer needs four things:

• Idempotency. Processing an event twice must produce the same result as processing it once. Log event IDs and skip ones you've seen.
• Order independence. Don't assume "created" arrives before "updated." Reconcile against current state instead.
• Fast acknowledgment. Return a 2xx before the slow work, then process asynchronously. An endpoint that finishes the accounting update before responding will time out under load and trigger retries you didn't want.
• Signature verification. A webhook endpoint is a public URL. Verify the signature or you're accepting instructions from anyone who finds it.

The failure nobody plans for is the silent one: your endpoint is down for four days, the retry window closes, and the events are simply gone. Nothing alerts you, because from the vendor's side nothing went wrong. That's the argument for the reconciliation sweep.

Polling intervals are a pricing decision

On a hosted automation platform, "how often" is answered by your plan, not by engineering. Zapier documents polling intervals of 15 minutes on Free, 2 minutes on Professional, and 1 minute on Team and Enterprise — and distinguishes all of those from instant triggers, where the app pushes data via webhook as the event happens.

That distinction matters more than the interval. A 15-minute cycle means "up to 15 minutes late": irrelevant for a nightly report, decisive for a lead handoff. Check whether the connector you need is instant or polling before you buy the plan — platform choice turns on this more than on feature lists.

What to ask before you buy "an integration"

Vendors list integrations the way restaurants list ingredients: accurately, and without telling you much. Get answers in writing to five things.

1. Which objects and fields sync? Usually a subset. Custom fields usually aren't included.
2. Which direction? One-way is far more common than two-way, and marketing pages rarely say which.
3. How often? Ask what "real-time" means in minutes.
4. What happens on delete? Deletions propagate in some integrations and not others. Silent non-propagation is how two systems drift apart over a year.
5. What happens on conflict? If both sides changed the same record, which wins — last write, or a designated master?

If a vendor can't answer these, the integration exists but hasn't been thought about, and you'll be the one finding its edges.

When not to integrate

Some connections aren't worth building. If two records need to match twice a week and it takes someone four minutes, a subscription plus a maintenance burden is a bad trade. Automation earns its place on volume, error rate or speed, and a low-stakes copy-paste has none of those.

Equally, don't integrate a process you're about to change — connecting two systems freezes the current shape of the work into code — and if the process itself is broken, integration only makes it broken faster. Invoicing shows both: choosing invoice automation software is mostly a question about your approval workflow, and only then about which system connects to which.

Frequently asked questions

What is an API in plain English?

An API — application programming interface — is a defined set of requests one piece of software will accept from another. It's the difference between a person clicking through a screen and a program asking for the same information directly. When your accounting system pulls yesterday's transactions from your payment processor without anybody logging in, that's an API call. The vendor publishes what you may ask for, in what format, and how often. An API is a contract: predictable, documented, versioned and rate-limited.

What is a webhook used for?

A webhook is used when something needs to happen immediately after an event, without waiting for a scheduled check. The system where the event occurred sends a message to a URL you supply, within seconds. Common uses are notifying a CRM that a payment succeeded, alerting a team channel when a form is submitted, or starting a fulfillment process when an order is placed. The tradeoff is reliability: webhooks can arrive twice, arrive out of order, or fail to arrive at all if your endpoint is unavailable when the sender's retry window closes.

What happens when you hit an API rate limit?

Requests start being rejected, typically with an HTTP 429 status, until the window resets. Well-built integrations back off and retry rather than hammering the endpoint, and many vendors return a header saying how long to wait. The practical risk is that a limit hit during a bulk operation leaves the job half-finished with no obvious signal that data is missing. Limits are published: Xero permits 60 calls per minute and 5,000 per day per organization; Salesforce Enterprise Edition starts at 100,000 requests per 24 hours.

Do I need a developer to integrate my business software?

Often not. Hosted automation platforms maintain connectors to thousands of applications and cover most common connections without code. You need a developer when no connector exists for a system you depend on, when the logic is genuinely complex, when volume makes per-action pricing untenable, or when data can't leave your own infrastructure. A sensible sequence is native integrations inside software you already pay for, then a hosted platform, then custom work — each step costs more to build and more to maintain.

Are webhooks secure?

They can be, but not by default. A webhook endpoint is a publicly reachable URL, so anyone who discovers it can send it data. The standard protection is signature verification: the sender signs each payload with a shared secret, and you verify the signature before acting on the contents. Stripe's libraries also check the message timestamp, defaulting to a five-minute tolerance, to limit replay attacks. Beyond that, use HTTPS, treat webhook data as untrusted input, and confirm anything consequential by calling the sender's API rather than trusting the payload alone.

How do I know if an integration is actually working?

Not by whether it ran, but by whether the two systems agree. The most useful monitoring is periodic reconciliation: count the records that should exist on both sides and alert when the numbers diverge. Success logs mislead — an integration that silently stopped receiving webhooks logs nothing at all, because from its perspective there were no events. Add a heartbeat that alerts when an expected event type hasn't arrived within a normal window, and check the vendor's own delivery logs, which usually show failed attempts your side never saw.