Data protection
Controller/processor roles, data categories, retention, US residency, DPA request channel.
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 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
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 below.
Data categories
What we store, broken out by source.
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
| 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
| 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
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; contractual commitments on residency are in the DPA.
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 to initiate.
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). Returns the event stream we hold for that user id. - Deletion. Today: email security@layers.com with the project id and the
user_idvalues to erase. We delete within 30 days, usually within one business day. ADELETE /v1/projects/:projectId/events/users/:userIdendpoint is planned (see 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
| 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
- 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_idin your project is scoped to your organization.
Getting a signed DPA
Today: email 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.