What Is a Webhook? A Plain Guide for Business Teams

How a webhook works

There are three parts.

1. An event. Something happens in the sending system, such as "invoice paid" or "new contact created".
2. A URL. The receiving system has a web address that accepts messages. You paste that address into the sending system once, during setup.
3. A payload. The sender posts a small package of data to the URL. It usually says what happened, when, and to which record.

The receiver answers with a quick "got it" and then acts on the message. It might update a record, send a notification or start a longer workflow. The whole exchange takes a second or two.

That is all there is to it. A webhook is not a product or a protocol you install. It is a simple agreement: when X happens, send a message here.

Webhook vs API

People often set these against each other, but they solve different problems. An API lets one system ask another for data or tell it to do something. A webhook lets a system announce that something happened. One is a question, the other is a notification.

Without webhooks, a system has to poll. It asks "anything new?" every few minutes, and most of the time the answer is no. That is slow and wasteful. With a webhook, the news comes to you.

In practice the two work as a pair. The webhook says "order 4812 was paid". Your system then calls the API to fetch the full order and update what it needs. For a wider look at the patterns, see our guide to business system integration.

Examples from daily work

Webhooks sit behind a lot of ordinary handoffs.

• Payments. A customer pays an invoice. The payment tool tells your CRM, the deal is marked won and finance gets a message.
• Lead forms. Someone fills in a demo request on the website. The form tool sends the details to the CRM and a sales rep is assigned within seconds.
• Support. A customer replies to a closed ticket. The helpdesk reopens it and posts a note in the team channel.
• Signups. A new user registers in your product. Your onboarding flow starts without anyone exporting a list.
• Stock. An item drops below a set level. The warehouse system warns purchasing before it runs out.

Each of these could also run on a timer that checks every hour. The difference is the wait. A lead who hears back in two minutes is in a different mood than one who waits until after lunch. For more ideas, see our workflow automation examples.

What goes wrong

Webhooks are simple, and that is also their weakness. When one fails, nothing looks broken. The message just never arrives. These are the usual causes.

• The receiver was down. If the receiving system is offline for a minute and the sender does not retry, the event is lost.
• Duplicates. Many senders retry when they get no answer. That is good, but it means the same event can arrive twice. The receiver has to notice, or you end up with two invoices.
• Out of order. An "updated" message can land before the "created" one. Workflows that assume a neat order will trip.
• No proof of sender. A webhook URL is a public address. If the receiver does not check a signature or a secret, anyone who finds the URL can post fake events.
• Silent changes. The sender renames a field in the payload and your workflow stops matching. Nobody is told.
• No owner. Someone set it up two years ago and left. When it breaks, nobody knows where to look.

None of this is a reason to avoid webhooks. It is a reason to pick tools that handle these cases for you, and to keep a short list of which integrations exist and who owns each one.

Questions to ask a vendor

When you compare tools, the phrase "supports webhooks" on a feature page tells you very little. Ask these instead.

1. Which events can trigger a webhook? A tool that only sends "record changed" is far less useful than one that names the exact event.
2. What happens when delivery fails? Look for automatic retries over a sensible period, not one attempt.
3. Is there a delivery log? You want to see what was sent, when, and what the receiver answered.
4. Can messages be verified? Signed payloads or a shared secret should be standard.
5. Is it on my plan? Some vendors keep API and webhook access for their top tier. Check before you sign.
6. Who can create and edit them? Access should follow roles, so one person cannot quietly reroute customer data.

If you are weighing a separate automation tool against one built into your suite, our piece on choosing a Zapier alternative walks through the trade-offs.

Where WeldConnect fits

Most teams do not want to write code that receives webhooks. They want the result: when this happens, do that.

WeldConnect is the automation builder inside WeldSuite. You pick a trigger, add actions across the suite and external tools such as Stripe, Slack and Google Sheets, and it runs in the background. Workflows can run in real time or on a schedule. Branching conditions handle the "only if" cases, and failed runs are retried automatically. Role-based access controls who can edit a workflow, and there are templates to start from.

Because WeldCRM, WeldDesk, WeldMail and WeldChat live in the same suite, many handoffs need no webhook at all. The data is already in one place. Webhooks and the API are there for the tools outside the suite. Our guide to business process automation shows how to decide what to automate first.

WeldConnect is one of twelve apps included in every WeldSuite tier. WeldSuite is a complete software suite for mid-market and enterprise teams, priced per user per month. There is a free plan for a single user. Business is $49 a month, or $42 per user per month billed annually, for up to ten seats, and it includes API and webhook access. Scale is $69 a month, or $59 per user per month annually, for eleven seats and up. Enterprise is custom, with SSO, SAML, data residency, and a 99.999% uptime SLA.

Sources

1. Wikipedia: Webhook https://en.wikipedia.org/wiki/Webhook
2. Wikipedia: API https://en.wikipedia.org/wiki/API

Frequently asked questions

Keep reading