Webhook

A webhook is an integration mechanism through which one application automatically sends an HTTP notification to a URL defined by another application, right when a relevant event happens (for example, a sale closes, a payment is approved or an order is delivered). Instead of the receiving system having to ask over and over "has anything new happened?", it is the sending system that lets you know as soon as it happens. That is why webhooks are often described as a "reverse API" or as HTTP callbacks.

The core piece is the receiving endpoint: a public URL that listens for those notifications and, when it gets one, triggers an action (saving a record, sending a message, updating a field). Webhooks are one of the most common ways to connect business tools to each other, and they are part of the integration work we coordinate on Salesforce projects when the CRM has to be linked to payment gateways, e-commerce platforms or messaging channels.

How a webhook works, step by step

A webhook flow always has the same players: a system that sends the notification and a system that receives it. First, in the sending system (say, a payment gateway) you configure a destination URL and choose the events you care about (payment approved, payment declined, refund). When one of those events happens, the sender builds a message, usually in JSON format, with the event data, and sends it to your URL through an HTTP POST request. Your endpoint receives that request, reads its content (the payload) and runs the logic you defined. Finally, your system replies with an HTTP status code (ideally a 200) to confirm it received the notification correctly.

That acknowledgment is key: if your endpoint does not respond in time or returns an error, most providers retry the delivery later, sometimes for hours. That is why a well-built endpoint responds quickly (it confirms receipt) and handles the heavy work afterward, in the background.

Why it matters for the business

The big advantage of a webhook is that it works in real time and efficiently. The classic alternative is polling: your system asks the other one every few minutes "is there anything new?". Polling wastes resources (most queries come back empty) and adds delay (you only find out on the next query). A webhook flips the logic: you do not ask anything, you get notified as soon as there is news. For a company, this means processes that react instantly: a customer pays and the order is released automatically, a lead fills out a form and lands in the CRM right away, a shipment is delivered and the customer gets the notification with no human involvement.

Webhook vs API: how they differ

Webhooks and APIs are often confused because both connect systems, but the difference is the direction and the trigger:

In practice they complement each other: a webhook tells you that something happened, and your system often responds by calling the provider's API to pull the full record.

A concrete example in Argentina

Picture an e-commerce business that takes payments through Mercado Pago and runs its CRM on Salesforce. When a buyer pays, Mercado Pago fires a webhook to the store's endpoint. Within seconds, that notification sets off a chain: the order is marked as paid, the stock is deducted, the e-invoice is generated and a WhatsApp confirmation goes out to the customer. Without webhooks, the team would have to check the payments dashboard by hand or schedule periodic queries, with the resulting delay and risk of error. The same applies to Calendly notifying you of a booked meeting, an e-signature platform confirming a signed document, or a logistics system reporting a delivery.

Common mistakes and precautions

• Not validating the source. Since your URL is public, anyone could send it fake data. Good providers sign every delivery (for example, with an HMAC signature in a header) so you can verify the notification really came from them.
• Not handling retries or duplicates. The same event can arrive more than once. The endpoint should be idempotent: processing the same notification twice must not duplicate the order or the charge.
• Processing everything inline. If your endpoint takes too long, the provider treats it as down and retries. It is better to respond quickly and hand the heavy work off to a queue.
• Trusting the arrival order. Events do not always arrive in sequence; your logic should tolerate an "order delivered" showing up before an "order shipped".

In integration projects, webhooks are often combined with iPaaS or middleware platforms, which receive the notification, transform it and route it to the right system, adding security, retries and traceability without having to code everything from scratch.