Key takeaways
- A webhook is event-driven: the source app pushes a message when something happens.
- An API call is a request you make; a webhook is a notification you receive.
- Webhooks keep tools in step quickly without constant checking.
- Receivers should verify each message, handle repeats and log failures.
How does a webhook work
A webhook works by subscription. You tell the source app which events you care about and give it a web address, called the endpoint, that belongs to the receiving app. When the event happens, the source sends an HTTP request to that address with details of what changed.
The receiver replies to confirm it got the message, then acts on it. If no confirmation arrives, many senders try again later, and most sign each message with a shared secret so the receiver can check it really came from the source.
What is the difference between a webhook and an API
The difference between a webhook and an API is the direction of the conversation. With an API, your app asks a question when it wants an answer; with a webhook, the other app tells you when something happens. An API is pull, a webhook is push.
They usually work together. A webhook might say "deal 4821 was updated", and the receiving app then calls the API to fetch the full deal. Webhooks are faster and lighter than checking an API every few minutes, but they only carry what the sender chooses to include.
What is a webhook example in a sales stack
A webhook example in a sales stack is a form submission that creates a CRM contact within seconds. Other common uses follow the same pattern of one event triggering work elsewhere, for example:
- A deal marked won posts a message in the team chat and starts an onboarding checklist.
- A meeting booked through a scheduling tool updates the lead's status in the CRM.
- A hard bounce from the email tool flags the contact so nobody emails it again.
- A new trial sign-up in the product creates a task for the account owner.
How to use webhooks safely
Using webhooks safely means treating every incoming message as untrusted until checked. The endpoint is a public address, so anyone who finds it can send data to it.
- Verify the signature on each message before acting on it.
- Expect the same event twice and make sure processing it again does no harm.
- Reply quickly and do the heavy work afterwards, so the sender does not time out and retry.
- Log failures and alert someone, because a silent broken webhook leaves systems out of step.
- Send only the personal data the receiver needs.
Where Pebbles Ai fits
Common questions
Are webhooks real time?
Close to it. A webhook is sent when the event happens, so the delay is usually seconds, although retries after a failure can add more.
Do webhooks need a developer to set up?
Receiving them usually needs either a developer or an integration platform that provides an endpoint for you. Choosing which events to send is often a setting in the source app.
What happens if a webhook fails?
Many senders retry for a while, then give up. Without logging and alerts on the receiving side, the missed event can leave two systems quietly out of step.
About this page. Written by the Pebbles Ai team for people who run sales, marketing and growth. Last updated .
