...
You can create and manage multiple custom webhooks and URLs each with individual settings. When called, a webhook will be validated first and then after this an internal message gets produced, pipelines . Pipelines can listen to this message using event.listen
or message.receive
to consume and process the incoming webhook finally. This way you can make sure, webhooks comply with a given set of rules before they will be passed across multiple pipelines, queues and optional microservices:
...
Webhooks are used to trigger actions on the backend. They are designed as async message senders from external. If you need more advanced requirements like direct responses, specific response headers or similar, consider to use the API Gateway instead.
Create a Webhook endpoint
Before some external service can call your webhook, you have to create and endpoint for it. You can create such a webhook using the command webhook.put
. Here is an example using it in a pipeline:
Code Block | ||
---|---|---|
| ||
pipeline:
- webhook.put:
eventKey: "webhook.lead.created" |
Or you can use the CLI to create the Webhook
Drawio | ||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Webhooks are used to trigger actions on the backend. They are designed as async message senders from external. If you need more advanced requirements like direct responses, specific response headers or similar, consider to use the API Gateway instead.
Create a Webhook endpoint
Before some external service can call your webhook, you have to create and endpoint for it. You can create such a webhook using the command webhook.put
. Here is an example using it in a pipeline:
Code Block | ||
---|---|---|
| ||
pi commandpipeline: - webhook.put: eventKey: "webhook.lead.created" |
Or you can use the CLI to create the Webhook:
Code Block | ||
---|---|---|
| ||
pi command webhook.put eventKey=webhook.lead.created |
The possible parameters to create a webhook are:
...
In case the polling result doesn't exists or was cleaned-up in the cache already, a status code 410 GONE is returned.
...
Consume a webhook call (trigger pipeline by a
...
webhook)
After you have successfully setup the webhook, any time the webhook url is triggered (called) from the outside, a new event + message is produced inside PIPEFORCE, which can then be consumed by any pipeline. To do so, use the event.listen
or message.receive
command to listen for such new event messages.
Using event.listen
Here’s an example which sends an email whenever a new lead was created using a webhook with the eventKey
=webhook.lead.created
:
...
. The pipeline uses the event.listen
command to handle the incoming webhook call:
Code Block | ||
---|---|---|
| ||
pipeline: - event.listen: eventKey: webhook.lead.created - iam.run.as: systemuser - mail.send: to: name@company.tld subject: "New lead was created!" body: ${@convert.fromBase64(body.payload.origin)} |
...
Code Block | ||
---|---|---|
| ||
pipeline:
- event.listen:
eventKey: webhook.lead.created
- iam.run.as: systemuser
- mail.send:
to: name@company.tld
subject: "New lead was created!"
body: ${body.payload}
|
...
Note |
---|
Since a Webhook triggers the execution of pipelines, they can be very powerful. This power also comes with additional responsibility for you, the app developer. Make sure you have sufficient security testings in place, and you have secured your webhook pipelines accordingly. |
Using message.receive
Any incoming webhook call is in the first place validated in the backend and then produces an internal event with name webhook.<name>
. In your pipeline you can directly fetch this event using the command event.receive
at this point.
Additionally, any webhook event is also forwarded to the messaging system as a common PIPEFORCE system message so it can also be handled as notification: Notifications. The key of this forwarded message is the event key prefixed with pipeforce.event
. For example if the webhook event key is webhook.lead.created
, then the message key will become pipeforce.event.webhook.lead.created
.
See the drawing from the beginning again here to visualize the difference of event.listen
and message.receive
:
Drawio | ||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Info |
---|
Since version 10 the message key of a webhook message has changed to the common PIPEFORCE event format and therefore is always prefixed with |
Listening to a webhook this way works similar to event.listen
. Just create a pipeline and put the command message.receive
at the very top but now listening to key pipeforce.event.webhook.lead.created
compared to the example above:
Code Block | ||
---|---|---|
| ||
pipeline:
- message.receive:
key: pipeforce.event.webhook.lead.created
- mail.send:
to: name@company.tld
subject: "New lead was created!"
body: ${body.payload}
|
List existing Webhooks
To list all existing webhooks, you can use the webhook.get
command:
...