I want an outside system to kick off my workflow the moment something happens, rather than polling on a schedule. How do webhooks work as a trigger in 3B? I’m curious how I get the URL, what the incoming data looks like, and how I use it in the steps that follow. A quick walkthrough would help me set this up correctly.
Webhooks are the way to go here! Instead of you asking “anything new yet?” on a scheduled timer, the outside system pings you the moment something happens. Here’s the walkthrough:
Getting the URL. Pick the step you want to be the front door (the one that receives the event) and give it a route (a path like /webhook). Since it’s an outside system calling in, set it up so it’s reachable with a secret link rather than a login: 3B generates a hard-to-guess ID and hands you back the full URL. You copy that URL and paste it into the other system’s webhook settings. That’s the handshake!
What comes in. When the event fires, the outside system sends you an HTTP request, and that whole request lands in your first step as its input. Most of the time the interesting part is the body, usually JSON describing what happened. Say it’s a new invoice; you might get something like:
{
"event": "invoice.created",
"invoice_id": "A-10432",
"customer_email": "sam@example.com",
"total": 89.90,
"created_at": "2026-07-21T15:04:00Z"
}
So your first job is to read that body and pull out the fields you care about: invoice_id, customer_email, and so on.
Using it downstream. Once you’ve parsed it, whatever that step outputs gets passed straight to the next step, and so on down the line. So the pattern is: step 1 catches the webhook and pulls out the fields you care about → step 2+ act on them (save it, message someone, call another API, whatever the workflow’s for).
Couple of important details:
- Respond quickly. A lot of systems expect a fast reply or they count it as failed and retry. Take the data in, hand it off, don’t make the sender wait on your slow work.
- Expect repeats. Webhooks can arrive more than once for the same event, so don’t assume every call is brand new. Build so a duplicate doesn’t cause double trouble.
- Test before you wire it up. You can feed your first step a sample request (like the one above) to make sure your parsing works before you point the real system at it.
Happy building!