Alert routing rules
Add a routing rule to an integration
Adds a rule at the end of the evaluation order, but ALWAYS above the first catch-all — a rule that matches everything stops evaluation, so anything placed under it would never be tried. That is what makes it safe to create the integration first and build its routing table afterwards: the catch-all created with recipient_group_uuid sinks as you add rules. Among rules that are not catch-alls, order is order of creation; use the reorder endpoint to change it. A rule with no severities, no statuses and no label matchers matches everything and is itself a catch-all. The call is NOT idempotent: repeating it adds a second identical rule.
post/api/v1/observability/integrations/{integration}/routing-rules
Request
- Base URL: https://wardenpoint.com (the document declares no server; this is the origin it was published from)
- URL: https://wardenpoint.com/api/v1/observability/integrations/{integration}/routing-rules
- Auth: API key in header X-API-Key
Path parameters
integrationstring uuid required
Integration UUID.
Request body
Example request
{
"label_matchers": [
{
"key": "service",
"value": "checkout"
}
]
}Response
Rule created.
Example response
{
"data": {
"label_matchers": [
{
"key": "service",
"value": "checkout"
}
]
}
}Changes
No recorded changes to this operation across all 1 revision of this API.