Destinations API
Chirpier still uses /destinations in the HTTP route names, but conceptually these are reusable alert destinations.
Manage Destinations
Start with the resource guide for destination strategy, example configs, and delivery workflow context.
Alert Deliveries
Pair destination setup with the alert guide when you need delivery-history and triage context.
Routes
POST /v1.0/destinationsGET /v1.0/destinationsGET /v1.0/destinations/:destinationIDPUT /v1.0/destinations/:destinationIDPOST /v1.0/destinations/:destinationID/test
Destination object
In the current API shape, the destination provider type is carried in the channel field.
{
"destination_id": "5e9d6fd1-727a-46f6-a377-6c8ef407efdc",
"channel": "slack",
"url": "https://hooks.slack.com/services/...",
"credentials": null,
"scope": "all",
"policy_ids": [],
"enabled": true,
"created_at": "2026-04-08T18:30:00Z",
"updated_at": "2026-04-08T18:30:00Z",
"last_delivered_at": null,
"last_error": null
}Supported destination provider types
| Channel | url | credentials |
|---|---|---|
slack | Incoming webhook URL | Not needed |
discord | Discord webhook URL | Not needed |
telegram | Not needed | {"bot_token": "...", "chat_id": "..."} |
webhook | Target endpoint URL | Optional {"authorization": "Bearer ..."} |
email | Not needed | Not needed (uses Chirpier’s mailer) |
Scope rules
Destinations can be constrained by:
scopepolicy_ids
That scope is matched during alert delivery.
Current matching logic:
scope="all"matches every alert for the workspace- otherwise, a destination only matches when the alert
policy_idis included inpolicy_ids
Create destination
Raw API
curl -X POST "https://api.chirpier.co/v1.0/destinations" \
-H "Authorization: Bearer $CHIRPIER_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"channel": "slack",
"url": "https://hooks.slack.com/services/T000/B000/secret",
"scope": "all",
"policy_ids": [],
"enabled": true
}'If the destination configuration is invalid, the API returns 400.
Read, update, and test
GET /v1.0/destinationsreturns all destinations for the current userGET /v1.0/destinations/:destinationIDreads one destinationPUT /v1.0/destinations/:destinationIDupdates an existing destinationPOST /v1.0/destinations/:destinationID/testsends a test notification and returns the synthetic testalert_idon success
Testing returns:
200 OKwith:
{
"alert_id": "414d5d9c-b8c0-4e8b-bf3a-0d4e3e616604",
"destination_id": "5e9d6fd1-727a-46f6-a377-6c8ef407efdc",
"status": "sent"
}404 Not Foundif the destination is missing502 Bad Gatewayif the downstream provider rejects the test send
Pair destination tests with GET /v1.0/alerts/:alertID/deliveries?kind=test using the returned alert_id when debugging delivery behavior.
Raw API
TEST_ALERT_ID=$(curl -s -X POST "https://api.chirpier.co/v1.0/destinations/$DESTINATION_ID/test" \
-H "Authorization: Bearer $CHIRPIER_TOKEN" | jq -r '.alert_id')
curl -G "https://api.chirpier.co/v1.0/alerts/$TEST_ALERT_ID/deliveries" \
-H "Authorization: Bearer $CHIRPIER_TOKEN" \
--data-urlencode "kind=test"Last updated on