Skip to main content
When Glassray detects a deviation, it can push a signed webhook to a URL you control. Your systems act on it the moment we find the problem - no polling - and you run whatever loop you like on your side: Glassray detects and emits, your harness decides and acts, and you write the outcome back through the API / MCP. Delivery is handled by Svix, so each request is signed, retried on failure, and inspectable in a delivery dashboard.

Register an endpoint

From Settings → Webhooks:
  1. Paste your endpoint URL (must be https:// and publicly reachable).
  2. Choose which events fire - Confirmed by default.
  3. Save. Glassray shows the signing secret once (starts with whsec_) - store it now; you use it to verify our calls.
You can register multiple endpoints, toggle them on/off, rotate the secret, send a test event, and view recent deliveries - all from the same screen.

When it fires

A webhook fires when a deviation reaches an actionable point in its lifecycle. Each event has a type:
We recommend keying your logic on the type field. The status inside the payload uses Glassray’s internal values - triage (Suspected), todo (Confirmed), done, cancelled.

Payload

Each event is thin but sufficient - enough to triage and act without a callback, plus deep links to fetch more. id is a stable event id you can use to dedupe.

Fields

Verifying signatures

Every request carries three headers you should verify so you know the call is really from Glassray:
Verify with the official svix library - pass the raw request body, not parsed JSON:
Verifying is a security control, not a requirement - the delivery works without it. But since the event can trigger automated action on your side, we strongly recommend it: the endpoint is public, so verification is how you know a call really came from Glassray.

Delivery guarantees

  • At-least-once. A confirmed deviation is delivered even across transient failures, so dedupe on the event id - the same event may arrive more than once.
  • Retries with backoff. A non-2xx response (or a timeout) is retried automatically. Return 2xx quickly and do your work asynchronously.
  • Inspectable. Every attempt - status, response code, retries - is visible under View deliveries in settings.

Closing the loop

The webhook is the missing push. Once your harness acts on an event, write the outcome back through the surfaces that already exist - mark the deviation Done or not-a-bug, or add a comment - via the MCP server (update_deviation_status, get_deviation, list_deviations).

MCP tools

Read and update deviations programmatically - the write-back half of the loop.