Is the payload schema stable?

Yes. New fields are added but existing fields never change shape. We treat the schema as a public API.

How are retries handled?

Exponential backoff with a max of 5 retries over ~30 minutes, then the delivery is marked failed and surfaced in the redrive UI.

Can I HMAC-sign the request?

Yes - set a shared secret per webhook. Lastest signs the body with HMAC-SHA256 and includes the signature in the X-Lastest-Signature header.

Can I send only on failures?

Yes. Filter by status - only fire on review_required and blocked, for example.

How do I test the endpoint?

Use the "Send test event" button in Settings → Notifications. Lastest POSTs a synthetic payload so you can verify shape and auth before going live.

Notifications

Pipe Lastest build events into any system you own

A stable JSON contract for build events you can route into PagerDuty, Statuspage, Linear, internal data pipelines, or your own ops bot. Custom headers, automatic retries, and a redrive UI for failed deliveries.

Try Lastest free →Read the docs

What you get

Three things this integration does - and what they mean for your team.

Stable JSON contract

A single event type - build.completed - with a stable schema. Status enum: safe_to_merge, review_required, blocked. Add fields are additive only; existing fields never change shape.

Custom method + headers

Configure HTTP method (POST, PUT, PATCH) and arbitrary headers per webhook - useful for HMAC-signed gateways, internal API keys, or routing through Cloudflare Workers.

Retries + redrive

Failed deliveries (non-2xx, timeout) retry with exponential backoff. The redrive UI lets you replay any failed delivery, with payload + headers + diff diagnostics.

How it works

Data flow, configuration, and result routing - visualised.

Diagram 1 · Event lifecycle

How a build event becomes an outbound HTTP call

Build completes → event written to outbox → notification dispatcher reads from outbox → matches routes → POSTs to each target → records delivery row with status + response.

Diagram 2 · Payload schema

The exact JSON your endpoint receives

Always includes: event, buildId, status, totalTests, passedCount, failedCount, changesDetected, flakyCount, gitBranch, gitCommit, buildUrl, timestamp. Fields are additive only.

Diagram 3 · Retries and redrive

What happens when your endpoint is down

Non-2xx responses and timeouts go onto a retry queue with exponential backoff. The redrive UI lets you replay any failed delivery once your endpoint is healthy again.

Configure

Drop-in config for Custom Webhooks

Exact build.completed payload Lastest delivers

{
  "event": "build.completed",
  "buildId": "abc123",
  "status": "safe_to_merge",
  "totalTests": 10,
  "passedCount": 8,
  "failedCount": 1,
  "changesDetected": 1,
  "flakyCount": 0,
  "gitBranch": "main",
  "gitCommit": "abc123",
  "buildUrl": "https://your-instance/builds/abc123",
  "timestamp": "2026-05-08T00:00:00.000Z"
}

Frequently asked questions about Lastest + Custom Webhooks

Is the payload schema stable?: Yes. New fields are added but existing fields never change shape. We treat the schema as a public API.
How are retries handled?: Exponential backoff with a max of 5 retries over ~30 minutes, then the delivery is marked failed and surfaced in the redrive UI.
Can I HMAC-sign the request?: Yes - set a shared secret per webhook. Lastest signs the body with HMAC-SHA256 and includes the signature in the X-Lastest-Signature header.
Can I send only on failures?: Yes. Filter by status - only fire on review_required and blocked, for example.
How do I test the endpoint?: Use the "Send test event" button in Settings → Notifications. Lastest POSTs a synthetic payload so you can verify shape and auth before going live.

Other integrations