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 | Limited operational retention |
| Request/response bodies | Full JSON | Not persisted beyond in-memory request scope |
| Idempotency cache | Body hash + replay envelope, keyed on Idempotency-Key | Replay window |
| Audit log | Create/update/delete on projects, keys, webhooks | Queryable via GET /v1/audit-log; longer retention available by contract |
Customer SDK events
| Category | Examples | Retention |
|---|---|---|
| Event envelope | Event name, user_id, timestamp, app id, properties JSON | Product analytics retention |
| 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 |
At the partner tier we can adjust retention by contract, subject to the minimum needed for the product to function.
Generated & inbound content
| Category | Examples | Retention |
|---|---|---|
| Generated media | Video/image assets produced for your projects | Project lifetime plus deletion grace period |
| Social-account metadata | Encrypted OAuth tokens, platform user id, handle | Until you revoke the account or the partnership ends |
| Public post metadata | Post IDs, engagement metrics, captions from connected accounts | Product analytics retention |
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. ADELETE /v1/projects/:projectId/events/users/:userIdendpoint is planned. - 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 | Limited operational retention |
| Idempotency cache | Replay window |
| 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.