Webhook Endpoints API

A webhook endpoint is a URL of yours that Zuse Bifrost posts events to, with the events it subscribes to and a signing secret you verify each delivery against. An endpoint belongs to the team and may be confined to one project; the secret is shown exactly twice, in the answer to registering the endpoint and in the answer to rotating it, and never appears on a read.

Each endpoint carries its delivery health: the last success and failure, the failure streak, and disabled_at when the worker switched it off after too many consecutive failures or when someone paused it. Pause and resume are the on/off switch, and events raised while paused are not queued or replayed; test enqueues a synthetic delivery so a new handler can be checked before real traffic; rotate secret revokes the old secret at once, so deploy the new one first. The delivery log and the replay of a dead-lettered row live under webhook deliveries.

Every member of the team may list and read endpoints, but only the member who registered one, or the team owner, may rotate, test, pause, resume or delete it. Endpoint lifecycle emits no webhooks of its own, since that would be recursive.

Background

Who may change an endpointCopy Anchor Link

Every member of the team can list and read the team's endpoints, but only the member who registered an endpoint, or the team owner, may rotate its secret, test it, pause or resume it, or delete it. A token minted by another member receives 403 FORBIDDEN on those calls; an endpoint outside the token's team is a 404 RESOURCE_NOT_FOUND, never a 403, so an id cannot be probed.

EndpointsCopy Anchor Link

Related

Webhook Deliveries APIThe delivery log, and how to replay a failed or dead-lettered row.Webhook Events APIConsume recent deliveries over REST.Webhook SecuritySignatures, public hosts and the IP allow-list.Ability CatalogueEvery ability string a token can carry, how the catalogue mirrors the team permissions, what enforces it on the API today, and how to pick the right ones when minting.