Notifications

Fire a notification from an alert template

Renders a stored alert template with the variables you supply and queues the result down the same path as POST /api/v1/notifications/send-async — escalation, channel fallback, retries and audit all behave identically. The point of the template is that the message wording, the priority and the addressee live on the server: you send the few values that differ per incident.

Always asynchronous. The answer is 202 the moment the job is queued, and it says nothing about delivery. On the single-recipient path the response carries notification_uuid — poll GET /api/v1/notifications/{notification}/status with that to learn what happened. On the group path there is no single notification to name: the response returns group_uuid only, and the individual notifications have to be found through GET /api/v1/notifications.

Addressing: the group always wins. The endpoint resolves a group first — override.group_uuid if given, otherwise the template's default group — and if a group comes out of that, the alert goes to the group and any recipient is ignored, including one you passed as override.recipient_uuid. To send a group-defaulted template to one person you must clear the group, which this endpoint cannot do; change the template instead. Only when no group resolves does the recipient path run, and with neither a group nor a recipient the call answers 422.

Not idempotent. Every call fires. There is no dedup key, no "only if not already sent" and no way to cancel from here — repeating the request after a timeout pages the same people twice. Each successful fire also increments the template's lifetime fired_count and stamps last_fired_at.

The slug is looked up inside the company of the API key, so a template of another tenant is simply not found. Firing consumes the same notification quota and the same rate limit as a direct send.

post/api/v1/notifications/from-template/{slug}

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/notifications/from-template/{slug}
  • Auth: API key in header X-API-Key

Path parameters

slugstring required
Example:db_down

Slug of the template, as configured in the dashboard. Letters, digits, underscore and hyphen only — anything else does not match the route and answers 404.

Request body

varsobject

Values for the placeholders in the template body, by name. A variable the template marks required and you omit fails the call with 422; a variable the template does not declare is ignored. Values are substituted as text — nothing here changes routing or priority.

versioninteger nullable

Pin the render to a specific stored version of the template body. Omit to use the current version, which is what you normally want — pinning is for reproducing an older wording. A version number the template never had answers 404.

Example request

{
  "vars": {
    "service": "mysql",
    "host": "db-01"
  }
}

Response

Rendered and queued. notification_uuid is present on the single-recipient path only; the group path returns group_uuid instead.

successboolean
queuedboolean
notification_uuidstring uuid

The queued notification. Single-recipient path only — poll its status endpoint with this. Absent on the group path.

recipient_uuidstring uuid

Who it went to. Single-recipient path only.

group_uuidstring uuid

Which group it went to. Group path only.

template_slugstring
template_versioninteger

Version number actually rendered — the current one unless you pinned version.

priority'low' | 'normal' | 'high' | 'critical'

Priority actually used, after any override.

rendered_message_previewstring

First 200 characters of the rendered body — enough to confirm the variables substituted as intended. The full text is what was queued.

Example response

{
  "success": true,
  "queued": true
}

Changes

No recorded changes to this operation across all 1 revision of this API.