A webhook is how an outside service tells your workflow that something happened. When a message is posted in Slack, a payment succeeds in Stripe, or code is pushed to GitHub, those services can send a request to a URL you give them, and that request kicks off your workflow. In Tines 3B, a webhook is simply a step set up to receive those incoming calls.
An endpoint that others call
Most triggers you set up in Tines 3B start a workflow from the inside: a schedule fires, or you run it yourself. A webhook is the opposite. It's an entry point that waits for someone else to call it. You hand the URL to an external service, and from then on that service reaches out to your workflow whenever it has an event to report. Your workflow doesn't poll or check; it just reacts when the call arrives.
Key characteristics
Event receiver: Webhooks function as endpoints that push event data into your Tines story.
Authentication: Webhooks typically use an external_id (a unique, unguessable identifier) to secure the endpoint. This allows external services to push data securely without requiring a user to be logged in to your Tines 3B tenant.
Data flow: The incoming HTTP request becomes the stdin of your webhook action. This includes the request line, headers, and the payload body. Once received, the action parses this data for use in downstream steps.
Visibility: When configured as a webhook, the endpoint is clearly marked on your workflow's Links page with a trigger icon, making it easy to identify for integration purposes.
Common use cases
Receiving real-time event notifications (e.g., Slack messages or GitHub repository updates).
Processing payment webhooks from platforms like Stripe.
Integrating any third-party service that needs to push data to your workflow.