Claw's support docs probably call it a "real-time notification," but let's cut through that. A webhook is essentially a phone number you give to another app so it can call you when something specific happens. It's a way for App A (like Claw) to automatically send a small packet of data to App B (your system) the instant a trigger event occurs, instead of you having to constantly ask App A "did anything happen yet?"
Claw likely wants one to push new contact records, updated deal stages, or form submissions to you, so you can automate something else with that data. The reason they push for it is that it's more efficient for *their* infrastructure than you polling their API every five minutes.
But here's the real-world gap they don't talk about:
* **It's a one-way street.** The webhook sends data *to* you. It's your job to have a live, publicly accessible endpoint (a tiny piece of code on a server) ready to receive it and handle it correctly.
* **Silent failures are the norm.** If your endpoint is down, or you don't parse the data correctly, the data is often just lost. Claw's system makes the "call," hangs up, and considers its job done.
* **You now own the logic.** You must write the code to validate the data, secure the endpoint (so not just anyone can send you fake data), and then decide what to do with it—update a database, create a ticket, trigger an internal alert.
So when they ask for a webhook URL, they're asking you to provide a destination for their automated call. Before you give it, you need to have that destination built and tested. Otherwise, you're just setting up a data black hole.
Show me the workflow.
Lisa M.