Data Handling

This page details how Zeotap processes, stores, transmits, and protects data across the platform. Understanding the data flow helps you assess Zeotap’s fit for your security requirements and configure it appropriately for your environment.

Warehouse-Native Architecture

The most important thing to understand about Zeotap’s data handling is the warehouse-native architecture: computation happens in your warehouse, and customer data stays under your control.

Zeotap connects to your data warehouse (Snowflake, BigQuery, Databricks, ClickHouse, Redshift, or Spark Lakehouse) with credentials you provide. When it evaluates computed attributes, builds audiences, or resolves identities, it generates SQL queries and executes them against your warehouse. The results are used to orchestrate syncs but are not stored persistently in Zeotap’s own database.

What Zeotap Stores

Zeotap’s metadata database (PostgreSQL) stores:

• Configuration metadata — Model definitions, audience filter expressions, computed attribute configurations, sync schedules, destination settings, orchestration canvases
• Encrypted credentials — Warehouse connection strings, destination OAuth tokens, API keys
• Operational state — Sync run status and summary metrics (row counts, error counts, timestamps), not the actual row-level data
• Audit events — User actions, API calls, sync run results, AI operations
• User accounts — Email addresses, roles, workspace memberships (authentication via Firebase/GCP Identity Platform)

What Zeotap Does NOT Store

• Customer PII (names, emails, phone numbers, addresses)
• Transaction or behavioral data
• Raw data from your warehouse tables
• Full sync payloads (individual records being synced)

What Data Leaves the Warehouse

Data leaves your warehouse only during activation — when audience members and their mapped fields are sent to destinations. This is the core purpose of a CDP: getting the right data to the right tools.

Activation Data Flow

The data that flows through Zeotap during activation includes:

• Identifier fields — The fields used to match records in the destination (e.g., email address, external ID)
• Mapped attribute fields — Only the fields you explicitly map in the sync configuration (e.g., first name, lifetime value, audience name)

Data is streamed through Zeotap during the sync run and is not persisted after the run completes. Only summary metrics (total rows synced, errors encountered) are retained.

Controlling What Data Leaves

You have full control over what data reaches each destination:

• Field mapping — Only fields you explicitly map are sent. Unmapped fields stay in the warehouse.
• Destination policies — Governance policies that restrict which audiences can sync to which destinations (learn more)
• Access policies — Row-level access controls that limit which records are visible to which users and syncs (learn more)
• Data minimization — Send only the fields each destination needs. Don’t send full profiles when an email address suffices.

Encryption

In Transit

All network connections use TLS 1.2 or higher:

At Rest

Sensitive data stored in Zeotap’s metadata database is encrypted:

Encryption keys are managed through your deployment’s key management configuration. In cloud deployments, keys are stored in a cloud KMS (Key Management Service).

Credential Storage

Credentials are treated as the most sensitive data in Zeotap’s metadata store:

• Held outside the database — Credentials are written to a secret manager and referenced by name; the metadata database stores the reference, not the secret. On Google Cloud the backend is Secret Manager, which encrypts at rest
• Never logged — Credentials are excluded from application logs, error messages, and stack traces
• Never returned via API — API responses redact credential values. Once set, a credential can be updated but not read back.
• Access controlled — Only Admin-role users can view or modify credential configurations
• Rotation supported — Credentials can be updated without disrupting existing syncs (the new credential takes effect on the next run)

Warehouse Connection Credentials

For each supported warehouse:

Destination Credentials

AI Model Inference

Zeotap’s AI features (Zeotap Agent and AI-assisted workflows) send requests to a large language model to interpret instructions and produce results. How that data is handled:

• What is sent — The conversation messages you write, plus the workspace context the AI needs to answer (configuration metadata such as model schemas, audience definitions, and tool results). Field mapping and access policies apply to AI-initiated operations the same way they apply to user-initiated ones.
• Where it is processed — Model inference runs on endpoints hosted in the European Union by default, so prompts and responses stay in-region.
• What is retained — The model endpoint does not retain prompts or responses beyond serving the request. Conversation history is stored by Zeotap subject to the AI conversation history retention setting (see Data Retention), and every AI operation is recorded in the audit log.

Audit Logging

Zeotap maintains a comprehensive audit log of all actions performed in the platform. Every audit event records:

Audited Actions

Audit Log Destinations

Audit events are written to two locations:

1. Zeotap internal store — Queryable via the UI (Settings > Audit Log). Over the API, the AI operations trail is available per workspace as GET /api/v1/workspaces/{id}/ai-audit-log; the rest of the audit trail is read from the UI or from your warehouse copy below.
2. Your warehouse — Written to the CDP_AUDIT.AUDIT_LOG table, where you can query them with SQL, join with other data, and apply your own retention policies

Data Retention

Zeotap supports configurable retention for operational data:

Retention settings are configurable per workspace in Settings > Data Retention. Data beyond the retention period is automatically purged from Zeotap’s internal store. Data in your warehouse is governed by your own retention policies.

API Key Security

API keys provide programmatic access to Zeotap’s REST API and MCP server.

Key Lifecycle

1. Creation — An Admin generates a key in Settings > API Keys. The full key is displayed once and must be copied immediately.
2. Storage — The key is hashed with SHA-256 and only the hash is stored, alongside a short prefix for identification. The original key cannot be retrieved.
3. Usage — Pass the key in the Authorization: Bearer header. Each request is validated against the stored hash.
4. Rotation — Generate a new key and revoke the old one. Active syncs and integrations should be updated to use the new key.
5. Revocation — Revoke a key immediately to block all requests using it.

Key Properties

Related Resources

• Compliance — GDPR, CCPA, and SOC 2 compliance support
• Govern — RBAC, destination policies, and access policies
• AI Guardrails — Safety controls for AI operations
• API Reference — API authentication details