MeriAI supports a narrow public widget surface for customer assistants and protected tenant APIs for governed staff workflows. This page summarizes recommended patterns — full contract details remain in the repository integration guide for engineering teams.
Website widget
Embed the public customer assistant on approved bank domains only.
Configure branding via tenant widget settings; chat uses POST /integration/widget/chat.
Issue a widget key per tenant and restrict allowed domains before production.
The widget never exposes internal tools, provider metadata, or competitor scopes.
REST API
Server-side integrations call governed endpoints such as /chat with tenant API keys.
Never embed admin API keys in browser bundles or mobile apps.
Use separate keys for public widget traffic vs staff/back-office integrations.
All factual responses remain citation-first with tenant scope enforcement server-side.
Mobile integration
Route mobile apps through your bank's secure backend — not directly to MeriAI admin keys.
Use short-lived sessions minted by your identity layer where SSO is available.
Distinguish public customer assistant mode from authenticated staff workspaces.
Log and audit server-side calls; do not cache secrets on device storage.
Keys, domains, and modes
Widget keys: domain allowlist + public customer mode only.
API keys: server-side, rotatable, scoped to tenant permissions.
Staff assistant: requires authenticated dashboard access and RBAC.
Production blocks development session-token shortcuts (ENABLE_DEV_AUTH=false).
Public vs staff assistant
The public customer widget answers within the current tenant's approved scopes and refuses competitor product questions. Staff and board modes require authenticated dashboard access, plan entitlements, and RBAC — they must not be exposed through the public widget or unauthenticated browser routes.