Data retention

How long an assessment is kept

Your organisation has one retention period, retention_days. It is 365 days by default, which is also the maximum, and you may shorten it to as little as 1 day. Every history page states the current value.

Each assessment expires from its own creation: expires_at is created_at plus the retention period in force when the assessment was created. Three rules follow from that.

• A later revision of the assessment, such as a phone source settling after the first answer, keeps the original expires_at.
• A new assessment for the same account does not renew an older one.
• If you shorten the retention period, every existing assessment’s effective expiry becomes created_at plus the shorter of the period at creation and the new period. Lengthening the period leaves existing assessments as they were.

After expires_at the assessment is gone. GET /v1/assessments/{assessment_id} answers 404, the assessment leaves the account’s history, and one last assessment.updated webhook arrives with status: "expired" and no assessment body. Expiry is not a revision, so assessment_version does not change.

The evidence references (evidence_ref) in a detailed answer expire with their assessment.

What else is kept

Record	Kept for
An outcome you report through POST /v1/assessments/{assessment_id}/outcomes	As long as its assessment. Outcome notes are stored for your records and not scored.
The Idempotency-Key of a create request	24 hours from first use, bound to the request body.
The Idempotency-Key of an outcome request	As long as the outcome is kept.
A history cursor	Until it expires; an expired cursor answers 400 invalid_cursor.
Your API key	The key id, your organisation, the scopes, the state and a keyed hash of the secret. The secret is shown once, at issuance or rotation.

Where identifiers travel

account_id travels in request and response bodies, not in a URL, and history is a POST with the account in the body, so account ids stay out of access logs and proxies. Logs, traces and error responses carry the key id, not the secret.

Values the API refuses

The request body has a field for each thing NoResponse uses, and an unknown member answers 400. These values are refused by shape:

Value	Where it is refused
A bcrypt, argon2, crypt or scrypt hash, a 40, 64 or 128 character hex digest, or a JWT	username, name and request_id. In account_id a hex digest is accepted, because a hash of an internal id is a common account id, and a JWT is refused.
An @, +, $ or whitespace	account_id. Use your own opaque id; the vertical bar is allowed so Auth0 ids pass unchanged.
Your auth provider’s session token	auth_context carries the verified claims; the SDK adapters build it from the user and session records.
A top-level tenant_id or any other unknown member	Anywhere. Your API key identifies your organisation.