# Encrypted areas

An **encrypted area** is a block of text or a file that is encrypted end-to-end: Aitronos
servers store only ciphertext and never hold a key that can read it. A sender attaches an
encrypted area in chat and sends it to another Aitronos user, an email address, a messaging
number, or as a shareable **secure link**.

There are two flavours:

- **Recipient-bound** — sealed to a specific Aitronos user. Only that user's identity can open
it; if the message is forwarded, the area stays sealed to the original recipient.
- **Secure link** — protected by a key that travels in the link (optionally further protected by
a password the sender sets out-of-band). Supports **burn-after-read** (self-destructs on first
open) and a configurable **expiry**.


In every case the storage layer holds only ciphertext — a compromise of storage yields no
plaintext and no key. Recipients open the area on an Aitronos-branded viewer and it decrypts on
their device. Files of any size are supported.

Encrypted areas are part of Conversations: where Conversations is enabled for your account they
are enabled with it, and where Conversations is switched off the create endpoint answers `403`.

## Creating an encrypted area

[Create an encrypted area](/docs/api-reference/encrypted-areas/create) encrypts inline text or an uploaded file, seals it for
the audience you choose, and either delivers it for you or returns a shareable secure link.

Three rules are worth knowing before you call it:

- **The secure link is returned exactly once and can never be re-issued.** The key inside it is
never stored, so nobody — including Aitronos — can produce it again. Capture it from the
response or create a new area.
- **The link is returned only for the `link` audience.** Every other audience is delivered for
you, so the response withholds the key-bearing URL.
- **The endpoint is not idempotent.** Repeating a request creates a second, independent area
with its own key; there is no de-duplication.


By default an area expires after 7 days; a password and burn-after-read are off unless you ask
for them.

## Opening an encrypted area

Both open flows are simple GET fetches that return the ciphertext plus the public parameters your
client needs to decrypt on-device:

- [Fetch a recipient-bound encrypted area](/docs/api-reference/encrypted-areas/fetch-recipient-bound) — authenticated; the
caller must be the bound recipient.
- [Fetch a secure-link encrypted area](/docs/api-reference/encrypted-areas/fetch-secure-link) — public; possession of the link
is the credential.


Both refuse an area that has **expired** or, for a burn-after-read area, that has **already been
opened**, returning `410`.

## Related resources

- [Create an encrypted area](/docs/api-reference/encrypted-areas/create)
- [Fetch a recipient-bound encrypted area](/docs/api-reference/encrypted-areas/fetch-recipient-bound)
- [Fetch a secure-link encrypted area](/docs/api-reference/encrypted-areas/fetch-secure-link)