Replaying captures

Updated

A replay sends a stored capture to the endpoint's destination as a new HTTP request. Replays run on the managed queue, so the page returns at once and the delivery's status updates as the queue works.

Set the destination

Each endpoint has at most one active destination. On the endpoint page, select Security settings, enter the Destination URL and select Save destination.

The URL must:

be an absolute http:// or https:// URL of up to 2048 characters;
have a host that resolves only to publicly routable addresses (no localhost, loopback, private, link-local or other reserved ranges);
contain no username or password, no #fragment, and no { or } template braces.

Otherwise the form shows: The destination must be an absolute HTTP or HTTPS URL with a publicly routable host.

Saving a different URL deactivates the old destination and creates a new one. Earlier deliveries keep showing the URL they were sent to, so history is preserved. Saving the same URL again changes nothing.

Queue a replay

Open a capture and select Queue replay. The page confirms Replay queued. and a new entry appears in Delivery history. Each click creates a separate delivery, so clicking twice sends the request twice.

If the endpoint has no destination, the page shows that the endpoint needs exactly one active destination instead of the button.

What is sent

The replay reproduces the capture as closely as is safe:

Method: the captured method.
URL: the destination URL, with the captured query string appended (joined with ? or & as needed).
Headers: the captured headers, except hop-by-hop and transport headers that would be wrong on a new connection: Connection, Content-Length, Host, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailer, Transfer-Encoding, Upgrade, and any header named in the captured Connection header.
Body: the stored body bytes.

Redacted values are replayed as they were stored, as the literal text [redacted by Bobbin]. A receiver that checks a signature or credential carried in a redacted header, or that parses a redacted body, will reject the replay. You cannot edit a payload before replaying it.

Delivery rules and retries

Each delivery gets up to four attempts. Before every attempt Bobbin checks the destination URL again against the rules above.

Result	What happens
`2xx` response	`succeeded`.
`429` or `5xx` response	Retried.
Connection failure or timeout	Retried.
`3xx` response	`failed` at once. Redirects are never followed.
Any other `4xx` response	`failed` at once.
Destination no longer passes the URL rules	`failed` at once.

Retries wait about 10 seconds, then 60, then 300, so a failing destination can take several minutes to reach failed. Each attempt allows 5 seconds to connect and 15 seconds for the response.

Delivery is at-least-once: a destination may act on a request before Bobbin records success, and that request may be sent again. Make your receiver tolerate duplicates.

Read delivery history

The Delivery history section of a capture lists every delivery, newest first. Each shows:

Status: queued, running, succeeded or failed. A delivery waiting for its next retry shows queued.
The destination URL it was sent to.
Attempts made so far.
Response status of the latest attempt, or No response received.
Latest safe error, such as Destination connection failed. or Destination returned HTTP 503.
When it was queued, started and completed.

A delivery's history is deleted along with its capture when the capture passes the retention window.

Replaying from an agent

An agent can list captures and queue replays through Bobbin's MCP tools, with an idempotency key so a retried call does not send twice. See Use Bobbin from your agent.