How Hookspot works
Follow one webhook from your webhook URL to the app on your machine.
Hookspot receives each webhook at a webhook URL, stores it, and forwards it through the CLI to the app on your machine. This page follows one webhook along that path.
- A sender posts to your webhook URL. The sender is the service that sends the webhook. Hookspot stores the request and answers the sender.
- Hookspot routes the request. Each route of the source gets its own delivery.
- The CLI receives each delivery.
hookspot listenmust be listening to the source. - The CLI forwards it to your app. Forward to your app shows the address your app gets.
- Hookspot records what your app answered. A
2xxstatus makes the delivery Delivered. Any other status makes it Failed.
Sources
Section titled “Sources”A source is a named webhook URL that a sender posts to. You name it in the New route dialog, and Hookspot creates its URL.
Webhook URL lists what the URL accepts and how Hookspot answers the sender. To send your own answer, see Reply to the sender.
Pause source on the source’s page keeps its URL working. Hookspot still stores each request, but marks it Rejected with Source disabled and delivers nothing.
Routes
Section titled “Routes”A route connects a source to a path in your local app, such as /webhooks.
You create one in the New route dialog from a source and a
Path in your local app.
A source can have several routes, one per path, as Send one webhook to several paths shows.
If a source has no route, or all of its routes or their paths are paused, Hookspot marks its requests Rejected with No route.
Requests
Section titled “Requests”A request is one webhook as the source received it: its method, URL, headers, query and body. Requests lists each one with its Outcome: Delivered, Failed, Skipped or Rejected.
A request with several deliveries shows the worst outcome among them, so one Failed delivery makes the request Failed. After you fix the cause of a Rejected request, click Replay to route the same request again.
Hookspot keeps requests for your plan’s retention period.
Deliveries
Section titled “Deliveries”A delivery is one request on its way along one route. Hookspot sends it to
every hookspot listen connected to the project. Each send is an attempt.
Hookspot records the first answer: your app’s status, headers and body. If the
CLI cannot reach your app, Hookspot records 502.
If no CLI listens to the source, the delivery is Skipped with CLI offline and gets no attempt. Hookspot does not send it again on its own. Start the CLI, then click Retry delivery.
Retries
Section titled “Retries”Hookspot tries a delivery again when the answer is 408, 429 or a 5xx
status. It waits longer before each retry and stops at five attempts.
Retry on a delivery sends it again whenever a CLI listens to its source. The Attempts tab lists every attempt with its own response and its trigger: Initial, System retry or Manual retry.
To send a request to your app again from the CLI, see Replay a request.