# Data protection (/docs/api/operational/data-protection) How Layers and partners divide responsibility for end-customer data, what we keep and for how long, and where it physically lives. For a countersigned Data Processing Agreement, email [legal@layers.com](mailto:legal@layers.com) with the signatory entity, countries of processing, and your requested governing law. The template we send follows the EU Commission's SCCs where applicable. This page describes current technical and contractual defaults. Commercial terms (signed DPA, custom retention, data-residency commitments, data-processing impact assessments) apply at partner tier under a mutual agreement. ## Roles [#roles] Under GDPR and CCPA terminology: * **You (the partner)** are the **data controller** for your end customers. You decide why and how end-customer data is collected and processed. * **Layers** is a **data processor** acting on your documented instructions. We process end-customer data only to deliver the services you've asked us to deliver (content generation, ad deployment, attribution). * For partner-representative data (the humans at your company who log into Layers or receive API keys), Layers is the controller. This distinction matters in practice. Data-subject requests (access, deletion, portability) from an end customer land with **you**. You ask us, we execute. See [Data-subject requests](#data-subject-requests) below. ## Data categories [#data-categories] What we store, broken out by source. ### Partner API traffic [#partner-api-traffic] | Category | Examples | Retention | | ----------------------- | --------------------------------------------------------------- | ---------------------------------------------------------------------- | | Request metadata | `requestId`, org id, API key id, endpoint, status code, latency | 30 days | | Request/response bodies | Full JSON | Not persisted beyond in-memory request scope | | Idempotency cache | Body hash + replay envelope, keyed on `Idempotency-Key` | 24 hours | | Audit log | Create/update/delete on projects, keys, webhooks | 90 days hot (queryable via `GET /v1/audit-log`) + 2 years cold archive | ### Customer SDK events [#customer-sdk-events] | Category | Examples | Retention | | ---------------------- | --------------------------------------------------------- | ---------------------------------------------------------------------- | | Event envelope | Event name, `user_id`, timestamp, app id, properties JSON | 400 days in primary event store, 2 years in aggregated event warehouse | | Hashed identifiers | SHA-256 of email/phone | Same as event envelope | | Raw email/phone | **Not persisted** — hashed before storage | N/A | | Device ids (IDFA/GAID) | Forwarded to platform CAPI when enabled | Not persisted server-side after forward | | IP address | Resolved to country/region at ingest, then dropped | Not persisted | The 400-day window covers a 52-week lookback for attribution analytics. At the partner tier we can reduce this on request; the floor is 30 days for the product to function. ### Generated & inbound content [#generated--inbound-content] | Category | Examples | Retention | | ----------------------- | --------------------------------------------------------------------- | ---------------------------------------------------- | | Generated media | Video/image assets produced for your projects | Until project archival + 90 days grace | | Social-account metadata | OAuth tokens (encrypted in vault), platform user id, handle | Until you revoke the account or the partnership ends | | Public post metadata | Post IDs, engagement metrics, captions from connected accounts + SIFT | 400 days | ## Data residency [#data-residency] All primary processing happens in the United States. Partner state, customer event records, and generated media are stored in US-region infrastructure. The current sub-processor list — naming each vendor that stores or handles partner or end-customer data — is on [Security & compliance](/docs/api/operational/security-and-compliance#subprocessors); contractual commitments on residency are in the DPA. ### EU partners [#eu-partners] Layers does not currently offer EU or APAC regional hosting — all primary processing is in the US. For EU partners who need to move personal data from the EU/EEA into the US, the DPA we countersign includes Standard Contractual Clauses as the lawful transfer mechanism — contact [legal@layers.com](mailto:legal@layers.com) to initiate. ## Data-subject requests [#data-subject-requests] When an end customer asks you (the controller) to access, delete, or port their data: * **Access / portability.** Use the existing per-user endpoints ([`GET /v1/projects/:projectId/events/users/:userId`](/docs/api/reference/telemetry/events)). Returns the event stream we hold for that user id. * **Deletion.** Today: email [security@layers.com](mailto:security@layers.com) with the project id and the `user_id` values to erase. We delete within 30 days, usually within one business day. A `DELETE /v1/projects/:projectId/events/users/:userId` endpoint is planned (see [Changelog](/docs/api/operational/changelog)). * **Rectification.** Send a corrected event via the SDK; the user's current-state properties will update. Past event records are immutable and represent what the SDK actually reported at the time. If the request concerns **hashed** identifiers (email/phone that never entered our system in plaintext), we can match deterministically only if you re-hash with the same normalization (lower-case + trim for email, digits-only for phone). ## Retention summary [#retention-summary] | Data class | Retention | | ------------------------ | ----------------------------------------------------------------------- | | Partner API request logs | 30 days | | Idempotency cache | 24 hours | | Audit log | Queryable via `GET /v1/audit-log` for the current partnership duration. | | Generated media | Project lifetime. | | OAuth tokens | Until revoked. | | Hashed PII (email/phone) | Same as the event it rides on. | Custom retention terms are negotiated under your DPA. ## What we don't do [#what-we-dont-do] * We don't sell or rent data to any third party. * We don't train foundation models on partner or end-customer data. Third-party LLMs we call (Vertex AI, OpenAI, Anthropic) are used with training opt-out / zero-retention modes where the vendor offers them; where not, only the narrowest prompt necessary is sent. * We don't build shadow profiles across partners. A `user_id` in your project is scoped to your organization. ## Getting a signed DPA [#getting-a-signed-dpa] Today: email [legal@layers.com](mailto:legal@layers.com) with: * The legal entity that will countersign. * Countries where **you** process data (so we know which SCC module applies). * Any customer-specific requirements (HIPAA, COPPA, FERPA, etc.) — flag these early; not all of them fit our current architecture. The default posture is click-through Terms of Service plus this page for everyone, and a countersigned DPA for partner-tier customers or anyone processing EU personal data at volume. We don't hide the difference — if what you need is a signed contract, say so. ## See also [#see-also] * [Security & compliance](/docs/api/operational/security-and-compliance) * [Status & support](/docs/api/operational/status-and-support) * [Rate limits](/docs/api/operational/rate-limits)