AI Dashboard agents, channels, and provider integrations

Configure each integration through its owning contract. AI Dashboard presents agent and integration workflows, the Ordering.co API authorizes core records and actions, and each channel or provider controls its own identity, delivery, limits, and failures.

Agent lifecycle boundary

The frontend can list, create, update, enable, disable, register, and monitor supported agent records through the API client. It also requests provider-setting schemas and renders forms from the returned schema.

• Treat the returned provider schema as the current form contract. Do not hardcode a provider inventory or copy secret fields into client constants.
• Validate in the UI for fast feedback, then rely on server validation and authorization for the final decision.
• Keep configured, enabled, site, SSL, and monitoring states distinct. One successful state does not prove that another boundary is ready.
• Mask known secret fields and never return a full credential to the browser after initial submission.
• Do not infer provider support from a component name or test fixture; confirm the provider schema returned for the intended environment.

Channels and conversations

Surface	Frontend responsibility	Server/provider responsibility	Failure boundary
Agent configuration	Render schema-driven settings, send authorized changes, and show sanitized status.	API validates the agent record; provider validates channel credentials and account state.	A saved record can still be unconfigured, disabled, or rejected by the provider.
WhatsApp connection	Present supported manual or business-login flow, lock provider-managed fields, and preserve the returned connection state.	API and Meta-owned flow exchange and protect credentials and external identifiers.	OAuth completion, provider review, phone state, and message delivery can fail independently.
Conversations	Query authorized conversations, render message history, and subscribe to supported realtime updates.	API owns access and history; socket/channel systems deliver events.	A live socket is not proof of complete history, and an API result is not proof of future delivery.
Voice or other channels	Present only schemas and routes returned as supported.	Provider owns media transport, identity, consent, and channel-specific limits.	Browser capability and provider acceptance remain separate.
Agent sites	Present site configuration and status returned by the API.	Site/deployment owner controls provisioning, DNS, certificates, and release state.	A domain or status value in an agent response is not independent deployment proof.

Importers and business integrations

The menu importer is a separate FastAPI service. The browser sends the signed-in bearer context, project and API context, selected businesses, and source-specific input. The service validates the source, fetches or receives source data, normalizes it to Ordering.co Menu Sync v2, can mirror supported images to object storage, and submits the normalized menu to the Ordering.co API.

Keep these outcomes separate:

1. source input accepted;
2. external source fetched;
3. data normalized;
4. optional images mirrored;
5. Ordering.co API sync accepted for each selected business; and
6. Dashboard cache invalidated and the resulting catalog re-read.

A partial import is not full success. Report per-business and per-stage failures without logging the bearer token, provider credentials, source payloads containing customer data, or private storage details.

POS, sales-channel, delivery, payment, and marketing integrations follow the same ownership rule: a visible card or feature flag allows the frontend to present a workflow; business access, plugin state, provider credentials, and provider acceptance remain independently enforced.

Provider security

• Keep service-role keys, internal shared secrets, OAuth client secrets, token-encryption keys, and provider access tokens outside the frontend and source control.
• Use server-generated and server-verified OAuth state. Do not construct callback results from browser query parameters alone.
• Keep redirect allowlists exact and environment-specific. Remove tokens and unnecessary provider detail from URLs, telemetry, and support captures.
• Store long-lived credentials encrypted through the approved backend path and track key rotation without exposing plaintext.
• Enforce consent, purpose, and channel policy when work is sent, not only when an integration is connected.

Failure and escalation

Observation	Next owner
The provider/type is absent from the schema response	API and product owner; do not create a client-only option.
Agent save succeeds but connection remains incomplete	Provider/authentication owner; preserve the saved and connected states separately.
Conversation history loads but live updates stop	Socket/channel owner; retain API history and diagnose delivery independently.
Import fetch succeeds but sync fails for one business	Menu-import and Ordering.co API owners; report the exact stage and avoid replaying successful businesses blindly.
OAuth returns but credentials are not persisted	Provider service and storage owner; do not expose persistence errors or secrets to the browser.

Related: Services and data boundaries · AI Dashboard engineering guide