Alert API and generic webhook

If your tool is not in the catalog, or you want to raise alerts from your own code, use the API integration. It accepts a small JSON body in which only a summary is required, and it can also acknowledge and resolve alerts. Its body is compatible with the Events v2 shape used by other paging tools, so a tool that already speaks it only needs a new URL and key.

#Set up the API integration

#Send an event

POST https://evohub.io/ingest/api with a JSON body. Send the integration key in whichever way your tool makes easiest:

• "routing_key" in the body,
• ?key= in the URL, or
• an Authorization: Bearer <key> header.

curl -X POST 'https://evohub.io/ingest/api' \
  -H 'Authorization: Bearer YOUR_INTEGRATION_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"summary": "Database primary is down"}'

curl -X POST 'https://evohub.io/ingest/api' \
  -H 'Content-Type: application/json' \
  -d '{
    "routing_key": "YOUR_INTEGRATION_KEY",
    "event_action": "trigger",
    "dedup_key": "db-primary-down",
    "payload": {
      "summary": "Database primary is down",
      "source": "db-01.prod.acme.example",
      "severity": "critical",
      "component": "postgres",
      "group": "payments",
      "custom_details": { "region": "eu-central" }
    }
  }'

curl -X POST 'https://evohub.io/ingest/api' \
  -H 'Content-Type: application/json' \
  -d '{
    "routing_key": "YOUR_INTEGRATION_KEY",
    "event_action": "resolve",
    "dedup_key": "db-primary-down"
  }'

#Request fields

You can send the alert details nested in payload (Events v2 style) or as flat fields at the top level. A flat field fills the matching payload field when that one is empty.

#Response

A processed event returns 202:

{
  "data": {
    "status": "success",
    "message": "Event processed",
    "dedup_key": "db-primary-down"
  },
  "success": true
}

Keep the dedup_key if you let EvoHub derive it — you need it to resolve the alert later.

A request that was not processed returns the same envelope with "status": "invalid event" and a message:

#How events behave

• Trigger opens an alert and starts the integration's escalation policy. A trigger whose dedup_key matches an alert that is still open does not open a second one; it is recorded as Retriggered on the existing alert.
• Acknowledge acknowledges the open, triggered alert with that dedup_key.
• Resolve resolves the open alert with that dedup_key.
• Acknowledging or resolving a dedup_key that has no open alert does nothing and still returns 202.
• The integration's escalation policy always applies; the request cannot choose another one.

#Generic alert webhook

EvoHub also accepts a simpler, flat alert format at /ingest/alerts. Create a Webhook integration for it (the key of an API integration works too):

curl -X POST 'https://evohub.io/ingest/alerts?key=YOUR_INTEGRATION_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "title": "Disk almost full on web-03",
    "description": "/var is at 93%",
    "severity": "high",
    "fingerprint": "web-03-disk-var",
    "labels": { "host": "web-03.acme.example" },
    "annotations": { "runbook": "https://wiki.acme.example/disk" }
  }'

curl -X POST 'https://evohub.io/ingest/alerts?key=YOUR_INTEGRATION_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "fingerprint": "web-03-disk-var", "status": "resolved" }'

The key goes in ?key= only. A missing title (on a trigger), or a resolve with neither a fingerprint nor a title, returns 400 with the code VALIDATION_FAILED and the field in details; a body that is not a JSON object returns 400 with INVALID_BODY; a bad key returns 401 with INVALID_KEY. A body larger than 1 MiB returns 413 with PAYLOAD_TOO_LARGE. A successful call returns 200 with {"data": {"received": 1, "created": 1, "resolved": 0}, "success": true}; resolved is the number of alerts actually resolved, so a resolve that matched no open alert answers 200 with "resolved": 0. This format cannot acknowledge; use the API events above for that.

#Alerts without a fingerprint

When a body has no fingerprint, EvoHub derives one from the title, the instance (alert_instance or the instance label), every label as key=value, and alert_service. Description, severity, alert_date and annotations are not part of it.

• Sending exactly the same alert again retriggers the open alert instead of opening a second one. (Before October 2026 every such send opened a new alert.)
• Alerts that differ in any label — another host, another region — are separate alerts.
• A resolve without a fingerprint must carry the same title, instance, labels and alert_service the alert was opened with.

If you want to choose the grouping yourself, send a fingerprint.

#Fingerprints belong to the integration

A fingerprint, sent or derived, only matches alerts opened through the same integration. Two integrations in one organization that send the same fingerprint open separate alerts, and neither can resolve the other's. EvoHub stores the fingerprint prefixed with the integration's ID; send it to this webhook as you always have, without the prefix.

#Limits

Titles are kept to 250 characters and descriptions to 4,000. At most 50 labels and 50 annotations are kept (the first 50 by key), with keys up to 64 characters and values up to 512. Longer text is cut, not refused, so the alert still opens.

#Moving from Parny

The generic webhook also reads the field names Parny's webhook uses. If a tool is already set up to send Parny's JSON, replace the Parny URL with your EvoHub webhook URL and leave the body as it is.

curl -X POST 'https://evohub.io/ingest/alerts?key=YOUR_INTEGRATION_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "alert_name": "High CPU",
    "alert_severity": "HIGH",
    "alert_instance": "es-01",
    "alert_service": "Elasticsearch",
    "alert_description": "CPU above 95% for 10 minutes",
    "alert_date": "10.10.2026"
  }'

Send the same body with "alert_status": "resolved" to resolve it. When a body carries both an EvoHub field and its Parny counterpart (for example title and alert_name), the EvoHub field wins.

#Tips

• Choose a stable dedup_key (or fingerprint) per problem, such as <host>-<check>, so repeats while the problem lasts do not open new alerts and your resolve finds the right alert.
• Send a resolve when your check passes again. Without one, the alert stays open until someone resolves it.
• Only new alerts count toward usage; retriggers of an open alert do not. See How billing works.

#Related

• Integrations overview
• Alerts and incidents
• Escalation policies