Rotate a webhook endpoint secret
Create-overlap-revoke rotation: mints a NEW signing secret (returned ONCE, same as create) and moves the CURRENT secret to `previous_secret_expires_at`-bounded overlap — the worker signs every delivery with BOTH secrets during that ~24h window so you can finish updating your verifier without dropping deliveries. Rotating a SECOND time before the first rotation's grace window elapses immediately drops the FIRST previous secret (there is only ever one previous-secret slot, not a stack) — do not chain rotations faster than your own verifier can keep up. Never mutates a secret in place; always mints fresh. Supports the optional `Idempotency-Key` header (a replay returns the SAME newly-minted secret again, never rotates twice for one logical request).
Create-overlap-revoke rotation: mints a NEW signing secret (returned ONCE, same as create) and moves the CURRENT secret to previous_secret_expires_at-bounded overlap — the worker signs every delivery with BOTH secrets during that ~24h window so you can finish updating your verifier without dropping deliveries. Rotating a SECOND time before the first rotation's grace window elapses immediately drops the FIRST previous secret (there is only ever one previous-secret slot, not a stack) — do not chain rotations faster than your own verifier can keep up. Never mutates a secret in place; always mints fresh. Supports the optional Idempotency-Key header (a replay returns the SAME newly-minted secret again, never rotates twice for one logical request).
Authorization
bearerAuth A gid_ API key (Settings → API keys) or an OAuth 2.1 access token.
In: header
Path Parameters
Header Parameters
Optional client-generated key (1-255 visible ASCII characters; a UUID works) making this POST safely retryable. Retrying with the SAME key and byte-identical body within 24h replays the stored first response (marked Idempotency-Replayed: true, never re-executed, never charged against quota). The same key with a different body answers 422 idempotency_key_reused; a retry racing the first execution answers 409 idempotency_in_progress. Omitting the header executes normally with no idempotency guarantee.
1 <= length <= 255Response Body
application/json
application/problem+json
application/problem+json
application/problem+json
application/problem+json
application/problem+json
application/problem+json
application/problem+json
application/problem+json
curl -X POST "https://example.com/v1/webhook-endpoints/string/rotate-secret"{ "id": "string", "url": "string", "enabled": true, "event_types": [ "task.created" ], "verified": true, "disabled_reason": "string", "created_at": "2019-08-24T14:15:22Z", "updated_at": "2019-08-24T14:15:22Z", "secret": "string", "previous_secret_expires_at": "2019-08-24T14:15:22Z"}Delete a webhook endpoint DELETE
Permanently (hard) deletes the endpoint — org-scoped, 404 for a cross-org or unknown id — mirroring how `deleteApiKey` hard-deletes a plugin key. The delete CASCADES (schema.prisma `onDelete: Cascade` on WebhookDelivery.endpointId, and from there to WebhookAttempt) to every delivery still queued for this endpoint: pending/in-flight deliveries for this endpoint stop existing rather than being left stuck. DELETE is naturally idempotent by HTTP semantics — this route does not use the Idempotency-Key ledger.
Verify a webhook endpoint POST
Live, synchronous probe: SSRF-checks the stored URL, then POSTs a signed synthetic test request (Standard Webhooks headers; event type `webhook.verification` — NOT part of the delivery vocabulary, never persisted as a WebhookEvent) and requires a 2xx to mark the endpoint verified. This is a re-runnable probe, not a consequential write — no Idempotency-Key support (`idempotent: false`). A failure reports `verified: false` with a `reason` and does NOT unset a previously-earned verified state.