Personal data in the KeenAuth APIs

KeenAuth processes your end users' personal data on your behalf, as your processor. This page lists, for each kind of personal data an endpoint can carry, what is stored, how long it is kept and how it is deleted. Every endpoint page that carries personal data links here from its "Personal data" section.

Do not send special categories of personal data

Do not put special categories of personal data (health, biometric data, religion, political opinions, sexual orientation), payment card data or identity document numbers in any field, and in particular not in user_metadata, app_metadata or names. KeenAuth does not inspect the content of metadata, so it cannot remove such data for you.

What KeenAuth does not store

• Payment card data.
• Raw SAML assertions and raw ID tokens from identity providers; only the mapped result is stored.
• Email and SMS bodies; only the template and the names of its variables are kept.
• The plain value of one-time codes and magic links; only a digest, until it expires.
• Biometric data: passkey biometrics stay on the user's device.

Retention and deletion by category

"Deleted with the user" means the data is removed when the user is deleted (see Deleting a user).

End-user profile

Email addresses, phone numbers, username, names, picture, locale, time zone, external_id and metadata. Kept while you use KeenAuth. Deleted from live data within 1 hour of a deletion request and from backups within 30 days.

Credentials

Password hash, TOTP secret, recovery code digests, and a passkey's public key, signature counter and AAGUID. Deleted immediately when the method is removed or the user is deleted.

Linked identities

The identity provider's subject, issuer, connection, mapped attributes and group identifiers. Deleted when the identity is unlinked or the user is deleted.

Sessions

A digest of the session id, IP address, user agent, device label, country and network (ASN), and last activity. Deleted 30 days after the session ends or is revoked.

Organization memberships and invitations

Organization name and slug, memberships, role assignments and the invitation email address. Kept until deleted; an invitation is deleted 30 days after it is accepted, declined or expires.

Directory (SCIM) users

Attributes your directory provisions: externalId, userName, names, email addresses, active, group memberships and the extra attributes you map. Deleted on deprovisioning or when the directory connection is deleted. Raw SCIM request bodies are neither stored nor logged.

Environment logs

User id, full IP address, user agent, method, outcome and risk signals. A failed attempt with an unknown identifier records a keyed digest of the identifier, never the email address, phone number or username itself. Kept according to your plan: Free 7 days, Startup 14 days, Business 30 days, Enterprise 90 days (365 days with the add-on).

Audit events

Actor, action, target id and a summary of the change, plus the events your application writes with POST /v1/audit-events. Kept for 1 year; Enterprise contracts can extend this to up to 7 years. An audit export file is kept for 7 days.

Events

The event payload: ids and the names of the changed fields. Personal data values are included only for fields you explicitly choose for an event type. Kept for 30 days.

Consent records

Document version, status, method and time of each acceptance or consent. Kept for the user's lifetime plus 3 years; pseudonymised when the user is deleted.

Privacy requests

Request type, status, due date and the requester's contact details when the requester is not the user. Kept for 3 years after the request is closed.

Dashboard users and account contacts

Name, work email address and role of your dashboard users and account contacts. Kept for the lifetime of the account; deleted 30 days after a dashboard user is removed.

Deleting a user

• One user: DELETE /v1/users/{user_id} returns 202 with a deletion_id. Live data is deleted within 1 hour; backups age out within 30 days. A deletion cannot be undone.
• Many users: POST /v1/jobs/user-deletions deletes up to 10,000 users per job through the same path.
• Self-service: when enabled for the environment, a user can request deletion of their own account. The deletion runs after the grace period you configure (0 to 30 days, 14 by default), and the user can cancel it during that period.

Backups are not edited to remove a single user; they are encrypted and expire after 30 days.