## Content and journal {#overview}

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 {#what-adal-stores}

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 {#what-adal-does-not-store}

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 {#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 {#where-data-is-stored}

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 {#retention-period}

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-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 {#request-size-limits}

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](/en/docs/outbound/sending#limitations). 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 {#security-and-access}

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](/en/docs/common/traffic). See [Regions](/en/docs/common/regions) and [Retries](/en/docs/common/retries).