Data sovereignty

Last updated: May 8, 2026

Note: If these Terms, Policies, or Agreements are available in multiple languages, and any discrepancies exist between translations, the English version shall prevail.

---

BabySea operates as an execution control plane for generative media workloads. This means BabySea receives generation requests, validates them, manages execution state, routes workloads across inference providers, handles billing and credit settlement, delivers webhook events, and exposes operational visibility through one API.

BabySea does not retain control over the internal processing performed by third-party inference providers. Customers should review the respective provider's data processing terms where their compliance obligations require provider-level review.

This page explains where BabySea stores persistent data, where compute may happen, how global edge infrastructure fits into the service, and how regional analytics, event streaming, caching, and provider routing are handled.

1. Data regions

When you create a BabySea account, you select a data region. Your account data, generation records, API logs, webhook logs, credit ledger, consent records, API key metadata, and stored output files are stored in the database and storage infrastructure for that selected region.

Each region operates its own database, authentication, storage, cache, routing data, analytics data, and operational infrastructure. BabySea does not automatically synchronize customer persistent data across regions.

Your selected region is the primary storage boundary for persistent BabySea data.

2. Source-of-truth data

BabySea uses Supabase as the transactional source of truth for each region.

The source-of-truth layer stores records such as:

• Account and team records.
• Authentication and membership metadata.
• API key metadata and bcrypt-hashed key values.
• Generation records and lifecycle state.
• Credit ledger entries.
• Billing references and subscription state.
• Webhook configuration and delivery logs.
• Consent records.
• API request logs.
• Activity logs.
• Output-file metadata.
• Event outbox records used for asynchronous event streaming.

The source-of-truth database remains regional. Derived systems such as analytics, event streaming, routing intelligence, and caches are designed to enhance the service without replacing the regional database as the authoritative record.

3. Edge compute

BabySea's application code runs on Vercel, which operates a global network of edge Points of Presence (PoPs). When you make an API request or load the dashboard, your request may be processed by an edge location close to the caller for performance and availability.

Vercel's current edge compute locations used by BabySea include:

Edge compute nodes execute application logic such as request validation, authentication checks, rate limiting, response formatting, and API orchestration close to the caller. They do not store persistent customer data. All persistent reads and writes are directed to the selected BabySea region.

For example, a request from Singapore to a US-region BabySea account may be processed by a nearby edge location, but the source-of-truth reads and writes occur in North Virginia.

4. CDN and network layer

Cloudflare provides DNS, CDN, WAF, DDoS protection, abuse prevention, and traffic analytics across BabySea domains globally.

Cloudflare operates a global network. Like edge compute, Cloudflare may process network traffic close to the caller for security and performance. Cloudflare does not serve as the source-of-truth database or persistent customer data store for BabySea account, generation, billing, or webhook records.

5. Event streaming and realtime infrastructure

BabySea may use realtime event streaming infrastructure to process operational events from the selected region. This includes generation lifecycle events, provider attempt telemetry, credit ledger events, webhook delivery events, routing-health signals, and system observability events.

BabySea's event streaming design follows these principles:

• Database remains the transactional source of truth.
• Event streams are derived operational data, not the authoritative billing or generation state.
• The BabySea API remains fail-open if the event streaming path is unavailable.
• Event streaming is used to improve observability, routing intelligence, and operational reliability.
• Replays of event streams may update derived systems such as analytics tables, dashboards, provider-health aggregates, and routing hints, but must not mutate source-of-truth financial or generation state.
• BabySea does not intentionally stream raw prompts, decrypted webhook secrets, raw API keys, customer emails, raw uploaded file URLs, webhook endpoint URLs, or unnecessary personal data through the realtime event backbone.

Event payloads are designed to contain operational metadata, identifiers, status transitions, timing information, provider telemetry, cost and credit events, webhook delivery results, and derived execution signals needed to operate and improve the service.

6. Analytics and routing intelligence

BabySea uses regional analytics and routing intelligence systems to improve provider selection, reliability, cost visibility, and execution observability.

Persistent data: account records, generation logs, API key metadata, webhooks, credit ledger entries, consent records, activity logs, and output files - is stored in the data region you selected.

Derived operational data: event streams, provider telemetry, routing rankings, health hints, aggregate metrics, and analytics tables - may be processed by regional analytics, streaming, and cache systems to operate and improve the service.

Transient processing: request routing, authentication checks, rate limiting, response formatting, cache lookups, and routing-hint reads - may happen at edge or cache layers, but those layers do not replace the regional source-of-truth database.

7. Inference providers

When you submit a generation request, BabySea may route it to a third-party inference provider. The provider processes the request and returns the result. Inference providers and their processing locations may vary by model, provider, media type, regional availability, and route configuration.

Supported providers listed in the List of subprocessors.

Where a provider offers regional endpoints or regional processing controls, BabySea may route requests to the endpoint that best matches the selected BabySea region. However, not every provider or model offers strict regional processing. Customers with specific sovereignty requirements should evaluate provider-level terms and contact BabySea for procurement or compliance review.

8. Adaptive provider routing

When a request specifies "fastest" as the provider order, BabySea selects provider order using regional execution intelligence.

BabySea may combine:

• Historical provider rankings computed from prior regional execution outcomes.
• Realtime provider-health hints computed from short-window provider telemetry.
• Circuit breaker state.
• Provider availability and model compatibility.
• Existing failover safeguards.

This routing intelligence is regional. For example, US provider rankings and realtime health hints are computed from US-region execution outcomes and are not automatically synchronized into EU or APAC rankings.

Explicit customer provider order remains customer-controlled, subject to existing compatibility, health, and failover safeguards.

9. Consent-based analytics

BabySea uses consent-based analytics technologies. Availability may vary by region:

Analytics data collection requires your consent where required by applicable law and can be managed through the cookie consent controls described in the Cookies policy.

10. Summary

Your persistent BabySea account and workload data lives in your selected region. Global edge and network infrastructure may process requests for performance and security, but does not act as the persistent source of truth.

BabySea may use regional analytics, caching, event streaming, and routing intelligence systems to improve reliability, provider selection, observability, and operational performance. These systems are designed as fail-open enhancement layers around the regional source-of-truth database.

For a full list of third-party processors and their purposes, see the List of subprocessors.

If you have questions about data location or need specific sovereignty documentation for procurement or compliance, please contact us.