Concepts

Modular Gateway

The platform is an API modular monolith: one Gateway process hosts all vertical services. Each service owns its routes and usually its own Postgres database, but they share one host, CORS stack, in-process events, and Identity.

Your app / SDK  →  Gateway (:5600)  →  Service module
Console Nuxt    →  Console API (:5501)  →  Gateway (JWT)

Documented public APIs are on the Gateway. The Console BFF is for the first-party Console UI.

Projects and environments

• A project is the top-level tenant container (billing, API keys, ownership).
• An environment (for example Development / Production) isolates service config, providers, and data within a project.
• Most customer APIs require both ids in the path:

/{service}/projects/{projectId}/environments/{environmentId}/...

Services catalog

Projects expose a catalog of enableable services (GET /projects/catalog). Per environment you enable services and attach provider settings (…/services, …/providers).

Providers

Services such as AI, Email, STT, TTS, Billing, and Storage can route work to configured upstream providers. Credentials and options live on the environment provider settings — not in client apps.

Some providers can optionally use a Tunneling public URL as the base address for local/self-hosted backends.

API keys

API keys belong to a project. Create, list, and revoke them via Projects APIs or the Console. See Authentication.

Base URL

Configure SDKs with the Gateway origin, for example:

http://localhost:5600

Production deployments use your Gateway public URL. Console NUXT_PUBLIC_GATEWAY_BASE should match the same origin your apps use for OIDC and API calls.

Health

Each service exposes GET /{service}/health (Identity uses /auth/health). Gateway root also serves GET /health.