Skip to main content
A webhook tells Nekt to notify your own system when something happens in the workspace. You register an https URL and the events you care about, and whenever one of those events occurs, Nekt sends a signed JSON payload to that URL. Use webhooks to react to pipeline failures, trigger downstream automations, or keep an external system in sync with activity in Nekt. Find them in Settings → Webhooks.
Webhooks are available on paid plans (Starter, Growth, and Custom). Only owners and admins can view and manage them.
Webhooks and Alerts complement each other. Alerts send email when a pipeline fails; webhooks send a machine-readable payload for any subscribed event to a system you control.

​
How it works

  1. You create a webhook with a name, an https URL, and a list of events to subscribe to.
  2. When a subscribed event happens, Nekt POSTs a signed JSON payload to your URL.
  3. Nekt records the result as a delivery you can inspect and resend.
Each delivery is signed following the Standard Webhooks specification, so your receiver can verify it with any of the published libraries.

​
Create a webhook

1

Open Webhooks

Go to Settings → Webhooks.
2

Add the endpoint

Enter a name and the https URL that will receive the events. HTTP (non-TLS), localhost, and private addresses are rejected.
3

Choose events

Pick the events to subscribe to from the checklist, grouped by resource. Select at least one.
4

Save the signing secret

After you create the webhook, Nekt shows the signing secret once. Copy it and store it securely—you use it to verify payloads, and it is not shown again.
The signing secret is shown only when you create the webhook or rotate its secret. If you lose it, rotate the secret to get a new one.

​
Events

Events are named resource.action in the past tense, for example source.created, pipeline_run.failed, permission.revoked, or user.joined. The create and edit dialog groups them by resource so you can subscribe to a whole group at once.
Organization-level events (invitations, access requests, a user joining, billing) are delivered to every subscribing webhook across the organization’s workspaces, each with its own workspace block in the payload.

​
Payload and verification

Nekt POSTs a JSON envelope:
The data block carries summary information about the resources the event points at (identifying attributes such as id, slug, name, status). A resource’s configuration and credentials are never included. Each request includes signature headers: Verify with the reference library:
Deliveries are sent at least once. A receiver may occasionally get the same webhook-id twice—deduplicate on it, and respond with a 2xx status to acknowledge.

​
Manage a webhook

Each webhook’s row menu offers:
  • Edit — change the name, URL, or subscribed events. Editing events replaces the whole selection.
  • Send test event — queues a ping delivery so you can confirm your endpoint receives and verifies it.
  • View deliveries — the recent deliveries, with event, status, HTTP response code, number of attempts, and sent time. Resend any failed delivery.
  • Rotate secret — generates a new signing secret (shown once). Use it if the secret may have leaked.
  • Remove — deletes the webhook and its delivery history.
You can also enable or disable a webhook with its toggle. A disabled webhook receives nothing.

​
Delivery reliability

  • Retries. A failed delivery is retried on a schedule spanning about 48 hours (ten attempts, starting seconds apart and widening to hours), so a brief outage on your side recovers on its own.
  • Status. A webhook is active, failing (deliveries are currently failing—the tooltip says since when), disabled (switched off by a person), or disabled automatically.
  • Automatic disable. If an endpoint fails continuously for 3 days and at least 3 deliveries in a row have exhausted their retries, Nekt disables the webhook and shows a banner with the reason. Re-enabling it with the toggle resets its health and resumes deliveries.
  • History. Delivery records are kept for 30 days.