For a business-critical CRM–ERP integration, the most reliable default is usually webhook in, queue in the middle, idempotent worker out. Receive the event quickly, verify it, acknowledge it, place it on a durable queue, process it asynchronously, retry transient failures with backoff and jitter, and send persistent failures to a dead-letter path that your operations team actually monitors.

That pattern matters for more than CRM and ERP. It also applies to e-commerce orders, payment events, help-desk tickets, inventory updates, WhatsApp workflows and AI automations that call business systems. The expensive failures are often not dramatic outages; they are quiet duplicates, missed updates, conflicting records and retries that create the same side effect twice.

Webhook, queue or polling: which one should you use?

These are not competing technologies. They solve different parts of the same integration.

Use a webhook when the source system can notify you that something changed. Webhooks reduce unnecessary polling and can make workflows feel close to real time. But the receiver should do very little synchronous work. GitHub’s current webhook best-practices guidance recommends returning a successful response within 10 seconds and suggests queueing webhook payloads for asynchronous processing.

Use a queue when the downstream work can be delayed, retried or processed independently. Microsoft’s Queue-Based Load Leveling pattern, last updated 12 June 2026, describes a queue as a buffer between producers and downstream services. This helps absorb bursts, decouple intake from processing speed and keep a temporary downstream outage from immediately breaking the caller.

Use polling when the source has no suitable event mechanism, when reconciliation is required, or when you deliberately want a periodic check. Polling is often useful as a safety net even when webhooks exist: for example, a nightly reconciliation job can compare yesterday’s orders in the ERP with the CRM or commerce platform and surface gaps.

A strong design often uses all three: webhook for fast notification, queue for reliable processing, and scheduled polling for reconciliation.

Why do duplicate records happen even when the API is working?

Because delivery and processing are different guarantees.

Many messaging systems are designed around at-least-once delivery, which means a consumer may see the same message more than once. Microsoft explicitly notes this in its queue-based load-leveling guidance and recommends designing consumers to be idempotent. Webhook providers may also redeliver an event after a timeout or failed response.

The fix is not “never retry.” The fix is idempotency: processing the same logical operation more than once should not create a different business outcome.

Stripe’s idempotent request documentation is a clear example. It allows clients to attach an idempotency key so a retry does not accidentally perform the same operation twice. Your own integration layer can use the same principle even when the downstream API has no native feature.

For example, if an e-commerce platform sends order ORD-8472 twice, the ERP worker should not create two sales orders. Store an immutable source event ID or a stable business key, check whether that event or operation has already completed, and make the second delivery a no-op or a safe update.

Do not rely only on timestamps. Retries, delayed deliveries and clock differences make them weak deduplication keys.

How should retries work without making an outage worse?

Retry only failures that have a reasonable chance of succeeding later.

A timeout, rate limit or temporary service unavailability may justify a retry. A malformed payload, missing required field or permanent authorization failure usually needs correction rather than repeated traffic.

AWS’s Builders Library article on timeouts, retries, backoff and jitter explains why aggressive retries can amplify overload. Exponential backoff increases the delay between attempts; jitter adds variation so many workers do not all retry at the same moment.

A practical policy can look like this:

  1. Retry a transient error a small number of times.
  2. Increase the wait between attempts.
  3. Add jitter to spread retry traffic.
  4. Respect the downstream provider’s rate-limit and retry headers when available.
  5. Stop retrying permanent validation or authorization errors.
  6. Move exhausted failures to a dead-letter path for investigation.

Google Cloud Pub/Sub’s current documentation, for example, supports exponential-backoff retry policies and dead-letter topics for messages that cannot be acknowledged after repeated delivery attempts.

What belongs in a dead-letter queue?

A dead-letter queue is not a trash bin. It is an operational worklist.

Send a message there when automatic retries have been exhausted or when the payload requires human or corrective action. Preserve enough context to diagnose the problem: source system, event ID, object ID, first-seen time, last error, retry count and a safe representation of the payload or reference to it.

Then monitor the queue. Microsoft’s current architecture guidance specifically recommends monitoring dead-letter queue depth so operations teams can investigate failures, fix the cause and resubmit messages when appropriate.

If nobody watches the dead-letter path, you have only moved the failure somewhere quieter.

Should the integration write directly from the webhook handler?

For a low-volume, low-risk integration, a direct synchronous call can be acceptable. But for business-critical operations, direct chains are fragile.

Imagine this flow:

Website → webhook endpoint → CRM → ERP → WhatsApp → analytics

If the webhook waits for every downstream system, one slow dependency can make the sender time out. The sender may then retry the webhook, while the first attempt is still partially running. That is how duplicate CRM records, duplicate ERP orders or repeated customer messages appear.

A more resilient pattern is:

Website → webhook endpoint → durable queue → workers → CRM / ERP / messaging / analytics

Each worker can have its own retry and failure policy. The webhook receiver can acknowledge quickly. The business operation becomes traceable instead of being one long synchronous chain.

A practical Saudi retail example

Consider a hypothetical Riyadh retailer with an online store, a CRM for customer follow-up and an ERP for inventory and finance.

When a customer places an order, the store emits a webhook. The integration gateway verifies the request, records the delivery ID and puts an order.created event on a queue. It immediately returns success to the commerce platform.

A CRM worker consumes the event and upserts the customer and order using stable source IDs. An ERP worker creates or updates the sales order using its own idempotency key. If the ERP is temporarily unavailable, the worker retries with backoff and jitter. If the payload fails permanently because a required product mapping is missing, the message moves to a dead-letter queue with the order ID and error details.

A nightly reconciliation process then compares the day’s source orders against CRM and ERP records. Webhooks provide speed; queues provide resilience; reconciliation provides a second line of defense.

If an AI assistant later needs order status, it should read from a controlled integration or API layer rather than becoming a new direct database dependency. The same reliable event and audit foundations make AI workflows easier to govern.

What should you monitor?

A dashboard that only says “API up” is not enough. Monitor the business flow.

Useful signals include incoming event count, queue depth, oldest unprocessed message age, success and retry rates, dead-letter count, duplicate-suppression count, downstream latency, reconciliation mismatches and time from source event to final business update.

Also keep correlation identifiers across systems. When a manager asks why order ORD-8472 is in the website but not the ERP, the team should be able to trace that order through the webhook, queue, worker and downstream response without searching five unrelated log systems manually.

A reliability checklist before go-live

Before launching a CRM–ERP or automation integration, confirm that:

  • every source event has a stable identifier;
  • webhook signatures or equivalent authenticity checks are validated where supported;
  • webhook handlers acknowledge quickly and avoid long downstream chains;
  • durable queues are used where delayed processing is acceptable;
  • consumers are idempotent;
  • transient and permanent failures are classified differently;
  • retries use limits, backoff and jitter;
  • persistent failures move to a monitored dead-letter path;
  • secrets use least privilege and are not embedded in client-side code;
  • logs carry correlation IDs without exposing unnecessary sensitive data;
  • reconciliation exists for financially or operationally important records;
  • there is a documented way to replay a failed event safely.

Reliable integration is less about choosing a fashionable platform and more about designing for the fact that networks, APIs and business systems sometimes fail.

FAQ

Are webhooks more reliable than polling?

They are faster and usually more efficient for change notifications, but they are not automatically more reliable. A durable queue, deduplication and reconciliation are what make the end-to-end workflow reliable.

Do we need a message queue for every integration?

No. Low-volume, low-risk synchronous integrations may not justify the extra moving parts. Add a queue when you need burst absorption, independent retries, decoupling or stronger failure recovery.

Is “exactly once” processing realistic?

Treat external delivery as if duplicates are possible. Idempotent business operations are often a safer design target than assuming every network message will be delivered and processed exactly once.

Where Masar Next can help

If your business needs to connect CRM, ERP, e-commerce, messaging or AI workflows, Masar Next’s Custom Services can help design the integration boundary, retry model and monitoring approach. For AI-enabled workflows, see AI Solutions. You may also find our guide on automation that respects the way teams already work useful when deciding what should be automated first.

Discuss your integration workflow with Masar Next.

Sources

Editorial note: This article was prepared with AI assistance and checked against the primary technical documentation linked above. It does not claim human expert, legal or regulatory review.