Back to documentation

Data storage and deletion

HTTP data retention, response storage, history after expiry and Server deletion.

View as Markdown
On this page

Content and journal

HTTP request content and its outcome record have different lifecycles. A visible journal row does not imply an available body; an absent body does not imply that delivery never happened.

Available data

Inbound exposes request metadata, HTTP content and recipient history. Outbound exposes a minimal submission journal, regional summary, diagnostics and original body. Outbound response bodies are stored only when the submission enables save_response_body.

What cannot be recovered afterward

If Outbound response storage was off, its body cannot later be retrieved from the journal. Enabling the flag for a new job does not recover an earlier response. Expired, removed HTTP data cannot be restored from request details either.

Rejected requests

A rejected Inbound request is not delivered and does not retain HTTP content for later reading. The journal can contain minimal diagnostic metadata. Do not treat such a record as a source body for resubmission.

Content location

HTTP data is stored in the Inbound receipt region or Outbound execution region. The request can remain visible in the journal even when its content is temporarily unavailable.

An accepted CLI job is also persisted in the client's local journal. That copy and its lifecycle depend on your computer; removing the regional body does not automatically delete the local copy.

Retention

HTTP data is retained for 90 days from request acceptance. Use the deletion deadline shown for the individual record. Retries, reads, traffic purchases and Free renewal do not extend it.

After expiry, cleanup removes content; minimal metadata and history may remain in the journal. Outbound reads of an expired body return 410; a summary can report available=false and reason=expired. Cleanup is not a promise to physically delete every copy at exactly that second.

Deleting a Server

Deleting an Inbound Server stops new intake at its address; the address is not reused. It is not an instruction to immediately erase all previously accepted requests: their content follows the original retention deadline. Check these consequences separately from disabling a Channel or deleting Router connections.

Sizes and incomplete responses

Inbound intake, the Outbound JSON envelope, request body, diagnostics and downloads have different constraints. Buying traffic does not change technical request constraints. For Outbound size errors, see the sending reference. Do not apply a limit from one flow to the other.

A stored Outbound response can be marked as incompletely read or truncated. Even if download is available, inspect these markers before treating the file as the recipient's complete response.

Security and your own storage

Restrict account and token access. Headers, paths, query and bodies can contain credentials and personal data; keep them out of ordinary logs and public screenshots. Use your own database and backups for long-term business data.

Expiry or content deletion does not reverse recorded traffic usage. See Regions and Retries.

Related documentation