Delete a tenant's webhook subscription
Permanently removes the subscription. Pending deliveries for this subscription will fail.
TENANCY:
- Under ApiKeyAuth: 404 on cross-tenant subscription.
- Under AdminKeyAuth: owning tenant resolved from
the subscription record. Primary ops use case is force-removing
a webhook that a tenant refuses to fix and is impacting
shared infrastructure.
AUDIT (NORMATIVE under AdminKeyAuth):
- Admin-driven deletes MUST record actor_type=admin_on_behalf_of
in the shared audit store. Callers SHOULD populate a
structured reason (e.g.,[WEBHOOK_FORCE_DELETE] abuse-report-42)
in the audit entry metadata for traceability.
PERMISSIONS: - ApiKeyAuth: requires webhooks:write permission on the API key. - AdminKeyAuth: no permission check beyond admin key validity.
Authorizations
Tenant-scoped API key for runtime operations (consistent with Cycles Protocol)
Administrative API key with full system access. Also accepted as an alternative to ApiKeyAuth on an explicit per-operation allowlist — the authoritative list is the union of operations whose security: block declares AdminKeyAuth (consult per-operation security blocks rather than this prose, which has historically drifted as the dual-auth surface expanded). When using AdminKeyAuth on list or fund endpoints, a tenant scoping parameter (typically tenant or tenant_id) is required for scoping (400 if missing) — the per-operation description specifies which. Lookup-style endpoints that uniquely identify a resource by non-tenant key (e.g. GET /v1/admin/budgets/lookup, where the (scope, unit) pair is unique) do NOT require a tenant parameter. Allowlisting is per-operation (exact method:path matching — no prefix matching, no wildcards) so new endpoints do not accidentally inherit admin-accessible status.
Parameters
Path Parameters
Responses
Subscription deleted