# Webhooks

Webhooks push events to your servers the moment they happen, so your systems react in real time instead of polling. A ticket is created, a customer signs in, an alert fires: each one reaches you as an HTTP request.

You configure the destination URL (and a shared secret) in the dashboard; your backend implements the receiver. This section documents every outbound event the platform sends: the payloads, the signature scheme and verification code, and the delivery guarantees you must design for.

| Event family | Configured at | Signed? |
|--------------|---------------|---------|
| Support-ticket events (`ticket.created` / `ticket.updated` / `ticket.comment_added`) | Support Tickets → Settings → Integration (`webhookUrl` + `webhookSecret`) | Yes, HMAC-SHA256 |
| Customer authentication (`customer.authenticate`) | Support Portal → Customer access → General login | Yes, HMAC + AES-256-GCM credentials |
| BugWatch alert-rule webhooks | BugWatch → Alerts → rule `webhookUrl` | **No** (see sub-folder) |

**Delivery semantics (v1):** fire-and-forget · 5-second timeout · **no retries** · duplicate deliveries are not expected but design your handler to be idempotent anyway. Respond `2xx` fast and do heavy work async.

**URL requirements:** HTTPS in production. Private/internal addresses (RFC1918, loopback, link-local, CGNAT, cloud-metadata ranges) are rejected at save time and re-checked at send time via DNS resolution.