Webhook Guides
Webhook Deleter
A webhook deleter should be boring and careful. Before deleting anything, identify whether you need to pause a route, disable future ingress, remove a stale destination, or permanently delete a resource.
FastHook supports safer cleanup workflows by separating sources, destinations, and connections. You can pause or disable first, inspect recent request and attempt evidence, then delete only the resource that is no longer needed.
Delete vs disable vs pause
- Pause a connection: hold delivery while keeping route identity and recovery scope.
- Disable a connection: stop future routing through that branch.
- Disable a source: reject future provider traffic without removing the URL record.
- Delete a resource: remove stale sources, destinations, or connections after inspection.
Delete a stale connection
curl -X DELETE "https://api.fasthook.io/v1/connections/con_123" \
-H "Authorization: Bearer $FASTHOOK_API_KEY" \
-H "x-team-id: $FASTHOOK_TEAM_ID"Delete a stale destination
Delete destinations after every connection that uses them has been removed or moved. If several routes share a destination, disabling or deleting it can affect more traffic than expected.
curl -X DELETE "https://api.fasthook.io/v1/destinations/des_123" \
-H "Authorization: Bearer $FASTHOOK_API_KEY" \
-H "x-team-id: $FASTHOOK_TEAM_ID"Delete a stale source
Delete a source only after the provider dashboard no longer points at its URL. When in doubt, disable the source first so future provider traffic is rejected with evidence instead of disappearing into an unknown state.
curl -X DELETE "https://api.fasthook.io/v1/sources/src_123" \
-H "Authorization: Bearer $FASTHOOK_API_KEY" \
-H "x-team-id: $FASTHOOK_TEAM_ID"Disable a source before deleting
curl -X PATCH "https://api.fasthook.io/v1/sources/src_123" \
-H "Authorization: Bearer $FASTHOOK_API_KEY" \
-H "x-team-id: $FASTHOOK_TEAM_ID" \
-H "Content-Type: application/json" \
-d '{ "status": "disabled" }'Cleanup checklist
- Check recent accepted and rejected requests for the source.
- Check failed events and destination attempts for the route.
- Pause or disable before deleting when you are unsure.
- Delete only after the provider dashboard no longer points to the source URL.
- Keep idempotency and replay windows in mind before removing receiver routes.
Deletion mistakes to avoid
- Deleting a shared destination before checking every connection that targets it.
- Deleting a source while a provider is still retrying failed deliveries to that URL.
- Removing routes before exporting the evidence needed for an incident review.
- Using deletion as a pause mechanism when a temporary connection pause would be safer.
- Replaying old events after deleting or recreating receiver routes without checking idempotency.
Recommended cleanup order
Clean up from the route inward. First pause or disable connections so no new destination attempts are created. Then confirm the provider no longer sends to the source URL. After that, remove stale destinations that are no longer referenced by any active connection. Delete the source last, because it is the piece provider dashboards and request history are most likely to reference during debugging.
If the webhook carried billing, fulfillment, identity, or support events, keep a short record of what was deleted and why. That runbook note is useful when someone later asks why a provider delivery no longer reaches an old receiver.