Run a job the moment another system says so.
An administrator gives another system a private URL. When it posts to that URL, DataBridge verifies the request and starts a job or a pipeline, passing the payload in as parameters.
Some work should start on an event, not on a clock: an order is released, a file lands, a build finishes. Polling every few minutes wastes runs and still adds delay.
Modules. Flow for the job or pipeline it starts, plus whatever modules the steps themselves need.
Edition. DataBridge Server. The sender must be able to reach the server's URL.
A real DataBridge screen, with sample data from a demo instance.
How DataBridge does it.
Each step names the feature as it appears in the product.
- Step 1
Webhook Triggers
In the administration area, create a trigger for a scheduled job or a pipeline. Each trigger gets its own private URL under /api/v1/hooks/.
- Step 2
Verification
Check the sender with an HMAC signature, a bearer token or both.
- Step 3
Parameters
Map values from the body, a header or the query string into run parameters. A query step reads them as @name, an HTTP request or email step as {param:name}, and an Import file step can read the body as its file with {webhook.body}.
- Step 4
Response
The request is answered at once with HTTP 202 and the run is queued, so the sender never waits for the work.
- Step 5
Run history
The run appears in Job Monitor like any other. A trigger runs with its owner's authority and does nothing if the owner has been deactivated.
What this does not do.
- Webhooks arrive over the network, so the DataBridge server's address must be reachable from the sender. Expose it deliberately and keep verification on.
- Webhook Sources, which store signed payloads from systems such as Stripe or GitHub, are a separate page from Webhook Triggers.
Related pages.
Try the parts that are free today.
The free browser edition needs no sign-in and never uploads your files.