Webhook Setup Guide

Receive alerts from external services directly into Task Ember's Inbox.

Overview

Webhooks let you connect external monitoring tools, CI/CD pipelines, or any HTTP-capable service to Task Ember. When an event occurs, the service sends a POST request to your webhook URL, and an alert appears in the Inbox.

Creating a Webhook

1. Navigate to Inbox
2. Click the Webhooks button in the toolbar
3. Enter a name and optional description
4. Click Create

You'll receive:

• Endpoint URL - The URL to send alerts to
• API Key - Authentication key for requests
• Signing secret - The key you sign each request with. It is shown only once, so copy it before you close the dialog

Sending Alerts

Send a POST request to your webhook URL with the API key, a delivery id and a request signature in the headers:

POST https://apim-taskember.azure-api.net/webhook/{databaseId}/{webhookId}
Header: x-api-key: {your-api-key}
Header: x-idempotency-key: {unique delivery id}
Header: x-taskember-timestamp: {unix seconds}
Header: x-taskember-signature: sha256={hex}
Content-Type: application/json

{
  "title": "Alert title",
  "severity": "critical" | "warning" | "info",
  "message": "Optional description",
  "source": "Service name",
  "metadata": {
    "key": "value"
  }
}

Signing a request

The signature is an HMAC-SHA256 over {timestamp}\n{delivery id}\n{raw body} (the timestamp, the delivery id and the exact body bytes, joined by newlines), keyed with your webhook's signing secret and sent hex-encoded. The API key still goes in x-api-key, but it is never the signing key. The timestamp must be within 300 seconds of the receiver's clock.

The delivery id is the value of the x-idempotency-key header, or x-event-id if that is absent. If you send neither, sign an empty delivery id. x-request-id is never used, because proxies can add or rewrite it. Always send x-idempotency-key: Task Ember drops duplicate deliveries by this id, so send a new unique value (a UUID works) for each delivery and reuse it only when retrying the same one. Signing it stops a captured request being replayed under a new id.

See the API Reference for worked cURL and PowerShell examples.

Webhooks provisioned for an uptime heartbeat monitor are the exception: their pings cannot sign, so they are accepted on the API key alone.

Rotating the signing secret

Open the webhook card and click Rotate signing secret in the Signing secret row. The new secret is shown once, and requests signed with the old one are rejected straight away, so update your senders right after.

Webhooks created before signing secrets existed are still signed the old way: an HMAC-SHA256 over {timestamp}.{raw body}, keyed with the API key. Because the API key travels with every request, click Generate signing secret on the webhook card to move the webhook onto its own secret.

Severity Levels

Sharing Webhooks

You can share webhooks with other users in your portal:

1. Open the webhook card
2. Click Share
3. Search for users or apply a member bundle
4. Users receive an invitation to the webhook

Member Roles

• Contributor - Can see the webhook URL and API key, upload documents, and send alerts. Only the owner sees the signing secret, so contributors get it from the webhook owner
• Assigned - Can view alerts from the webhook but cannot see credentials

Attaching Documents

Attach documentation to webhooks so Ask Ember (the AI assistant) can reference them when answering questions about alerts.

1. Open the webhook card
2. Click Docs
3. Upload text files, PDFs, or configuration files (max 5MB each, 10 files per webhook)

Ask Ember

The AI assistant in the Inbox can help you understand and triage webhook alerts. It reads:

• All alerts in the Inbox
• Documents attached to webhooks

Assign funds to Ask Ember and ask questions like:

• "What are my critical alerts about?"
• "How do I resolve the CPU alerts?"
• "Summarise today's webhook activity"

Webhook Actions

Configure automated actions that trigger when your webhook receives alerts:

1. Open the webhook card
2. Click Actions
3. Build action workflows using the visual builder

Actions can filter by severity, source, or metadata to route alerts appropriately.