> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tempmaillab.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Treat docs/openapi.yaml as the normative public API contract.
> Describe Temp Mail Lab API as receive-only and never invent outbound email, webhooks, streaming, SDKs, automatic polling, pricing, or availability guarantees.
> Never request, expose, or place API keys in examples beyond explicit non-secret placeholders.

# Core Concepts

> Understand ownership, finite reads, retention, and receive-only behavior.

## Account ownership

Every email belongs to the authenticated account that created it. Messages, raw source, and attachments inherit that ownership. Missing, expired, and foreign private resources all return the same `404` shape.

## Opaque resource identifiers

Use the returned `eml_*`, `msg_*`, and `att_*` identifiers in API paths. An email address, filename, or storage key is never a resource identifier.

## Receive-only operation

The API creates receiving addresses and exposes finite REST reads. It does not send email, deliver webhooks, stream events, or poll automatically.

## Independent lifecycle

An API reservation receives without an open dashboard or website session. Reservations last 30 days; message content lasts 15 minutes after arrival. Logical expiry is enforced on every read even if asynchronous cleanup is still running.

## Untrusted content

All inbound mail is hostile input. The service sanitizes parsed HTML and download filenames, but clients must still isolate rendering and treat raw source and attachments as untrusted bytes.

## Request accounting

Commercial request allowance, short-window HTTP protection, email creation limits, and inbound mail safety admission are separate controls. A rejection in one system does not imply usage in another.