> Keiro Labs API documentation - Data Retention > Page: https://docs.keirolabs.ai/data-retention.html > Markdown: https://docs.keirolabs.ai/data-retention.md > Agent index: https://docs.keirolabs.ai/llms.txt > API base URL: https://api.keirolabs.ai/v1 > Auth: send "Authorization: Bearer " with a key created in the > Keiro console (https://console.keirolabs.ai/api-keys). Use credentials saved by > `keiro setup`, or resolve the key from a secret manager or an owner-only > secret file and pass it to the client explicitly. Never read another > provider's variable, and never put raw key material in environment > variables, code, docs, or logs. # Data retention and erasure This page summarizes Keiro's paid beta data retention posture for invite-only eb1 access. It is a customer-facing summary, not a substitute for the signed beta terms, privacy notice, or DPA. ## Version Current paid beta retention posture version: `data-retention-2026-07-15`. This version supersedes `data-retention-2026-06-19`. Keiro may update this posture as the beta environment changes. Material changes are communicated through the support channel or agreement process before sensitive workloads are enabled. ## Paid beta: first-party retention During the paid beta, Keiro Labs retains supported API request and response payloads on first-party systems to operate, debug, and improve the service. Payload capture covers supported completion request bodies accepted by the endpoint and newly executed successful or terminal eb1 response bodies. Error responses, replayed responses, and streams that end without a terminal response object are represented only by the operational metadata described in the matrix below, not by a separate retained response body. Upstream model providers process requests to generate responses. Their handling is governed by the applicable provider terms and Keiro's configured data controls; see [Subprocessors](subprocessors.md). Retained traffic is access-controlled, is used only by Keiro Labs, and is not sold or shared beyond the subprocessors listed in [Subprocessors](subprocessors.md). This posture applies for the duration of the paid beta; it will be revised before general availability, and material changes are announced through the support channel before they take effect. If a workload cannot accept beta retention, do not send it during the beta, or contact `hello@keirolabs.ai` to discuss options. ## Retention matrix | Data class | Examples | Paid beta retention posture | |---|---|---| | Account and org identity | console users, orgs, memberships, invites | Retain while the org is active; deactivate or anonymize after closure when accounting, security, and legal records no longer require identity linkage | | API key metadata | key id, kid, role, tier, status, expiry, allowed models, limits | Retain active metadata while the key exists; retain revoked-key metadata for at least 2 years for security, abuse, and billing support | | Billing and usage records | org plans, billing records, usage events, adjustments, exports | Retain for 7 years where needed for accounting, tax, dispute, audit, and legal obligations | | Request logs without raw payloads | request id, org id, key id, trace id, model id, status, token totals, idempotency digest | Retain for up to 90 days for reliability, support, billing explanation, and abuse prevention unless a longer legal hold applies | | Prompt hashes and payload digests | prompt hash, payload artifact id/path, digest metadata | Retain for up to 30 days by default; redaction jobs clear payload artifact references while preserving accounting fields | | Beta retention artifacts | Supported completion request bodies and newly executed success/terminal eb1 response bodies | Paid beta: supported request bodies accepted by the endpoint and newly executed successful or terminal response bodies are retained first-party by Keiro Labs to operate and improve the service (see "Paid beta: first-party retention" above); error responses, replayed responses, and unterminated streams have operational metadata but no separate retained response body; upstream processing follows the applicable provider terms and configured data controls | | Debug payload artifacts | provider payload captures, route payload artifacts, SUR audit payloads | Disabled by default for paid beta; if explicitly enabled for an approved support or incident workflow, retain for no more than 30 days unless Legal approves a hold | | Redis idempotency and replay | idempotency claims, saved response replay, stream replay | Operational state only; target TTL is 24 hours or less and org/request cleanup is available after approval | | Redis rate/concurrency state | RPM, TPM, concurrency counters | Operational state only; expires with the active window and is not a billing source of truth | | Redis spend exposure | inflight reservations, settled day/month counters, reservation expiry metadata | Inflight reservations expire after the request safety window; settled counters are retained for at most 400 days for spend-cap enforcement and reconciliation | | Console sessions | signed host-cookie sessions, CSRF hashes, server-side revocation rows | Sessions expire after 12 hours by default and can be revoked immediately | | Console session recordings | admin-gated session replay and UX telemetry (masked at capture; sensitive regions blocked before any byte leaves the browser) | Off by default; when enabled for a named preview cohort, recordings and their event chunks are retained for up to 30 days and then hard-deleted, with org- and user-scoped erasure available | | Console audit and legal acceptance | invite acceptance, terms version, privacy version, key lifecycle, role changes | Retain for 7 years where needed for legal acceptance, security, and accounting evidence | | Incident and key-leak evidence | non-secret drill evidence, revocation evidence, customer communication evidence | Retain according to the incident severity and legal hold posture; never include credentials, private connection strings, or private prompts in evidence | ## Export Authorized org roles may request a customer-safe export through the console or support channel. Exports use allowlisted DTOs and may include org metadata, API-key metadata, plan and budget fields, usage summaries, usage CSVs, request ids, token totals, final billing status, invite metadata, membership metadata, and audit-event metadata. Exports do not include credentials, private connection strings, sensitive operational details, non-public vendor data, or raw error payloads. ## Erasure Keiro supports deletion or anonymization review for beta data, subject to security, abuse-prevention, accounting, dispute, and legal retention requirements. Billing rows, usage events, audit events, and legal acceptance records needed for accounting or legal obligations are retained rather than hard-deleted. Approved request-log payload redaction clears payload artifact references while preserving request ids, org/key identity, status, token totals, price-book version, and billing joins. Approved operational-state cleanup is scoped by org and request id while preserving records required for reliability and accounting. Retained records never include raw API keys, token hashes, admin tokens, provider credentials, DSNs, Redis URLs, or other secret material; only non-secret identifiers and accounting fields survive redaction. ## Support Send export, erasure, DPA, subprocessor, or data-retention questions to `hello@keirolabs.ai` or the beta support channel. Do not send API keys, external service credentials, private datasets, regulated data, or full logs that may contain secrets in the first request. ## Related pages - [Usage and billing](usage-billing.md) - [Legal and privacy](legal-privacy.md) - [Subprocessors](subprocessors.md)