Search before asking
Use case
Currently, Kibana v 8.19 webhook connectors require a fixed URL configuration per connector. This creates a limitation when integrating with devlake API webhook beacuse closing incident has dynamic path parameters like issueKey .
Kibana doen't support dynamically constructing the webhook URL using values from the alert context or previous action output.
As a result, it is not possible to reliably implement a “create + close” workflow using only Kibana alert with webhook actions when the external API requires the issueKey identifier in the URL path.
Description
Allow both “create” and “close” operations to use a fixed webhook URL.
Move all dynamic identifiers (e.g., issueKey) into the request body.
Workaround
At the moment, this limitation forces users to implement external middleware to store and correlate issueKey values between alert firing and recovery events.
Related issues
#8905
Are you willing to submit a PR?
Code of Conduct
Search before asking
Use case
Currently, Kibana v 8.19 webhook connectors require a fixed URL configuration per connector. This creates a limitation when integrating with devlake API webhook beacuse closing incident has dynamic path parameters like issueKey .
Kibana doen't support dynamically constructing the webhook URL using values from the alert context or previous action output.
As a result, it is not possible to reliably implement a “create + close” workflow using only Kibana alert with webhook actions when the external API requires the issueKey identifier in the URL path.
Description
Allow both “create” and “close” operations to use a fixed webhook URL.
Move all dynamic identifiers (e.g., issueKey) into the request body.
Workaround
At the moment, this limitation forces users to implement external middleware to store and correlate issueKey values between alert firing and recovery events.
Related issues
#8905
Are you willing to submit a PR?
Code of Conduct