Privacy and retention | MorphiaOne Docs

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

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.