> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.morphiaone.ai/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.morphiaone.ai/_mcp/server.

# Privacy and retention

You are sending us photographs of people's faces. That makes this page part of the
integration, not an appendix to it.

## The shape of the transport

The only accepted input is an **upload of the image bytes** to `POST /v1/assets`, as
the whole request body. You send the bytes; a job then names the asset by id.

EXIF, XMP and IPTC metadata — which can carry a location, a device and a timestamp —
are stripped before the asset is stored.

There is no remote-URL submission, so do not assume an SDK will accept a URL. If your
images live in your own object storage, fetch them on your server and upload the
bytes.

## What we hold, and for how long

| Thing                                               | Lifetime                                                                                           |
| --------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| An input asset                                      | until its `expires_at` — 24 hours after upload in the examples on this site                        |
| A job, and the input snapshot it took at submission | until the job's `expires_at`                                                                       |
| Result assets                                       | expire with their job, at the `expires_at` each one carries                                        |
| The idempotency record                              | outlives the job, so a replay still recovers the job id — see [Idempotency](/concepts/idempotency) |

Read `expires_at` rather than hard-coding a number: it is the value the service holds
you to.

Nothing in the queue between our own services carries image bytes or a caller URL —
it carries a private reference and integrity metadata. That matters to you because
it bounds where a copy of the face can exist.

## Result references are capabilities, not URLs

A result asset's `href`, `/v1/assets/{asset_id}/content`, needs your API key to
resolve, it is scoped to your account, and it stops working when the asset expires.
The bytes are served by the API itself, never through a redirect to storage. An input
asset's content is not served back at all: you already have those bytes.

Treat it accordingly:

* do not paste it into client-side analytics, a support ticket, or a log that leaves
  your infrastructure;
* do not hand it to a browser — it would not resolve without the key, and making it
  resolve would mean shipping the key;
* do not treat it as storage. Fetch what you need and put it somewhere you control,
  under your own retention rules.

## What never appears in an error or a log, on our side

No image bytes. No facial landmarks. No API key or fragment of one. No internal
file path, storage key or cache key. No upstream URL. This is enforced by tests
rather than by convention, because the failure mode is a face in a log aggregator.

## What your side has to get right

* **Never log the bytes.** Not at debug level, not "temporarily". Log the job id
  and the `request_id`; they are enough for support and they are not personal data.
* **Never log the key**, including a prefix. A prefix plus a length is a head start.
* **Use stable fixture ids for reproduction.** When you need to hand us a repro,
  give us the job id and the `request_id`, not the photograph.
* **Commit only licensed, consented fixtures.** A test image of a real person in a
  repository is a retention decision nobody reviewed.
* **Align your own retention with your privacy notice.** We delete our copy on the
  schedule above; the copy you keep is governed by what you told the person whose
  face it is.
* **Have a deletion path.** If a customer asks you to delete their data, your side
  needs to be able to do that without asking us — which means knowing which of your
  records hold face media.

## What this page is not

It is not a data processing agreement, a list of sub-processors, a certification
claim, or a retention guarantee expressed in a number we have not agreed with you.
Those live in your contract. This page is the engineering shape so your
implementation matches whatever that contract says.