Send alerts with the private webhook
Admin users can open Webhook generator to obtain the organisation's ingest URL and API key. The same endpoint receives alerts from supported payload formats and custom integrations.
Get the ingest URL and key
- Open Webhook generator as an Admin.
- Copy the Ingest URL.
- Copy the API Key.
- Store the key in your secret manager rather than in source control.
Send a request
Send the alert as a POST request with the API key in the X-Shankh-Key header.
Every field is optional — there is no schema validation. Shankh reads the first key it recognises from each group below, so most existing alert payloads work unchanged.
POST <ingest-url>
Content-Type: application/json
X-Shankh-Key: <your-api-key>
{
"title": "Checkout latency above threshold",
"description": "p95 latency 2.4s over 5 minutes",
"severity": "high",
"service": "checkout-api",
"workspace": "payments",
"source": "custom-monitor"
}| Incident field | Keys read, in order |
|---|---|
| title | alert_name · name · title · subject · summary |
| detail | description · message · body · text · details |
| service_name | resource · service · component · host · hostname · instance |
Set the severity
Severity is mapped from a wide vocabulary onto Shankh's four levels — sev1, p1, firing and down all become CRITICAL, for example. Anything unrecognised becomes INFO.
Know which workspace it lands in
Shankh resolves the workspace in this order and stops at the first match:
- The workspace named in the alarm metadata.
- A cloud resource whose display name matches the service — exact match first, then substring.
- The workspace of whoever is currently on call.
- The organisation's oldest workspace.
Close an incident from the same sender
Send the recovery with is_recovery set to true. Shankh matches it to the open incident by correlation key:
correlation_key = sha256(organisation | service_name | metric_name)A separate dedup hash of source, service, title and severity suppresses duplicate alerts inside a 5-minute window. It only suppresses — it never resolves anything.
Read the response
A created incident returns 201 with the payload wrapped in a success envelope. Response keys are camelCase — incidentId, not incident_id.
201 Created
{ "success": true, "data": { "incidentId": "…" } }| Status | Meaning |
|---|---|
| 201 | Incident created |
| 401 | Missing or wrong API key |
| 400 | No workspace could be matched |
| 429 | More than 100 requests a minute from this IP |
| 500 | Generic server error — retry with backoff |
Errors are not wrapped in that envelope. They return success false alongside statusCode, message, errors, timestamp and path — so a client that only reads data sees nothing at all on failure.
Verify that an incident was created
- Open Incidents and filter to the workspace you sent to.
- Confirm a new incident appears with the expected title, service and severity.
- Confirm the incident source shows the webhook sender.
- Confirm the assigned responder received a notification.
Rotate the key
- Prepare every sender to take a new key.
- Regenerate the key in Webhook generator.
- Update all senders immediately.
- Send a test request and confirm a new incident appears.