Webhook integrations built to retry, dedupe and recover

A webhook is an HTTP request that one system sends to a URL you choose as soon as something happens, such as an order being paid or a deal being won. Instead of your software asking for updates on a timer, the sender pushes each event to you with the details in the request body, usually as JSON.

An API is something you call when you want data. A webhook is the sender calling you when data changes. Most integrations use both: the webhook says that order 4471 was paid, and the receiver then calls the Zoho Books API to record the payment. Webhooks remove the need to poll for changes.

Most senders retry for a while on their own schedule, then give up, and some disable the endpoint after repeated failures. That is why we answer quickly, store every event in a queue we control, and run our own retries with backoff. Events that still fail go to a dead-letter queue for replay.

Exponential backoff means each retry waits longer than the last, often doubling: 5 seconds, then 10, 20, 40 and so on up to a cap. It gives a struggling system room to recover instead of hammering it. Adding random jitter spreads out retries so hundreds of queued events do not all arrive in the same second.

Senders deliver at least once, so the same event can arrive twice. We record each event ID when it is first processed and skip any repeat. For updates we also compare timestamps or version numbers, so an older event arriving late cannot overwrite newer data in Zoho CRM or Zoho Books.

Many senders sign each request. Stripe sends a Stripe-Signature header and Shopify sends an X-Shopify-Hmac-Sha256 header, both computed with a secret only you and the sender know. Our receivers recompute the signature over the raw body and reject anything that does not match. For senders without signing, we use a secret token in a header.

Yes. In Zoho CRM you create a webhook under the automation settings and attach it to a workflow rule, so it fires when records are created, edited or meet a condition. It can send chosen record fields to your URL. Zoho Books and Zoho Desk offer webhooks too, and Zoho Flow can receive webhooks from other apps.

For a few event types at modest volume, a Zoho Flow webhook trigger is usually enough. For payments, high volume or custom logic, we host the receiver as a function on Zoho Catalyst or on AWS with API Gateway, SQS and Lambda. The choice depends on volume, where your team already works and who maintains it.

Yes. Inherited receivers are a big share of our webhook work. We start with the delivery history and a count of records on both sides to find where events are dropped or doubled. Then we add the missing pieces, usually a queue, an event ID check and alerts, and replay what was lost where the sender allows it.

The first call costs nothing. After it, we write the event map, receiver design, retry rules and checks into a BRD with a fixed price and a delivery schedule, and you sign before we build. Larger setups, or ones already losing data, may need a short paid review first, priced up front.