AI Dashboard services and data boundaries

Place code where its authority, secrets, runtime, and failure recovery belong. A browser convenience is not a server control, and a storage row is not proof that an external provider completed its work.

Responsibility map

Layer	Owns	Must not own
apps/dashboard	Routes, forms, local interaction state, query caching, sanitized status, and operator feedback.	Service credentials, provider token exchange, authoritative authorization, or trusted cross-tenant data access.
packages/shared	Reusable API client, authentication and configuration state, query behavior, shared providers, utilities, and UI used by monorepo apps.	Product-specific secrets or a second server authorization model.
Ordering.co API	Core authentication, project and resource authorization, commerce records, AI-agent contracts, and supported integration mutations.	Provider promises that only an external system can make.
services/menu-import	Source adapters, fetch/transform pipeline, Menu Sync v2 normalization, optional image mirroring, and sync orchestration.	Browser presentation or replacement of the signed-in user's authorization with a static client credential.
services/meta-ads	Meta OAuth exchange, campaign and insight orchestration, provider error normalization, token encryption, and trusted persistence.	Exposing provider secrets or privileged database credentials to the browser.
supabase/functions	Narrow server-side link-in-bio administration/tracking and menu-import log operations defined by each function.	General-purpose bypass of Ordering.co API authorization or unrestricted database access.
Postgres/Supabase and object storage	Durable rows, policies, migrations, audit fields, and supported media objects.	Business truth about provider delivery unless that result is verified and recorded by the owning service.
External providers	OAuth identity, ad/channel accounts, external content, delivery, rate limits, and provider errors.	Ordering.co project authorization or browser navigation.

Data flow rules

1. The browser authenticates through the Ordering.co API contract and keeps only the session material required by the approved client flow.
2. Core Ordering.co data travels through the shared API client and remains project-scoped and server-authorized.
3. A standalone service receives the minimum context for its task. It validates the bearer or internal trust boundary before using privileged provider or storage credentials.
4. Provider data is normalized before it crosses into Ordering.co records. Preserve source provenance and a sanitized failure stage.
5. Storage writes occur through the backend role and row-level policy intended for that workload.
6. The frontend invalidates affected caches and re-reads the authoritative result rather than assuming that submission equals completion.

Storage boundaries

The repository includes Supabase migrations and functions for selected workflows. Treat migrations as versioned schema intent, not proof that a database has applied them. Before an authorized release, verify the target migration ledger and policies without printing connection strings or service-role keys.

• Browser clients receive only public configuration intended for browser use.
• Service-role credentials stay in trusted services or functions and must never use a VITE_ prefix.
• Provider access tokens are encrypted before persistence when the owning service supports storage.
• Object-storage writes use least-privilege credentials, explicit content limits, and sanitized object keys.
• Logs contain correlation identifiers and stage/status data, not raw menus, customer conversations, credentials, authorization headers, or signed URLs.

Failure ownership and recovery

Failed stage	Durable fact to keep	Recovery owner
Browser validation or request construction	Sanitized field/state error; no secret values	Frontend owner
Ordering.co API authentication or authorization	HTTP status, operation, correlation identifier, and project-safe context	API owner
External fetch or provider request	Provider category/code when safe, retryability, and correlation identifier	Standalone service/provider owner
Transformation or normalization	Source type, schema version, rejected field path, and fixture-safe sample	Import/service owner
Database or object-storage write	Operation, migration/policy version, and sanitized backend error	Storage/service owner
Realtime delivery	Last confirmed event or cursor and connection status	Socket/channel owner

Retries must be bounded and idempotent at the owning boundary. Do not replay a provider creation, campaign launch, menu sync, notification, or other consequential request unless its idempotency and prior outcome are known.

Security review triggers

Request security review before adding a new provider credential, public callback, service-to-service secret, cross-project query, privileged database role, unrestricted CORS origin, user-generated remote URL fetch, file upload, signed URL, or new customer-data field. Request privacy review before expanding conversation, analytics, advertising, or click-tracking collection or retention.

Related: Agents, channels, and provider integrations · AI Dashboard engineering guide