Portal

Purpose

The Portal is the administrative and operational surface of the platform. It combines a REST-based admin API with a web application used by platform administrators, tenant administrators, and operators.

Its functional role is to let human users configure everything that the Runtime later exposes and executes.

What The Portal Covers

The Portal is responsible for:

user sign-in and account management
interface display preferences
tenant and user administration
API onboarding
mapping authoring and publication
LLM connection and enrichment model management
toolset and client application administration
downstream security and credential setup
governance dashboards and audit review
portal notifications and operational visibility

Main Functional Areas

Detailed documents for each Portal area:

Authentication And Account Management

The Portal supports:

username and password sign-in
refresh-token based session continuation
logout
multi-factor authentication with TOTP
MFA backup code generation and regeneration
tenant selection when a user belongs to multiple tenants
account profile updates
self-service password change
password-change-required enforcement after an administrative password reset
active session listing and session revocation
super-admin session review and revocation across users
light and dark display mode switching with persistent preference

It also supports external portal sign-in through OIDC-compatible identity providers, including:

provider discovery
challenge and callback flow
tenant-aware login resolution
tenant selection when a user belongs to multiple tenants
optional email-based account linking

Supported external identity providers include Microsoft Entra ID and Keycloak.

The Portal now also fronts the browser-based runtime OAuth authorization flow used by local agents and other browser-capable clients:

the runtime authorization endpoint redirects into the normal Portal login page instead of using a separate embedded sign-in form
the authorization request is preserved across external-provider redirects, MFA verification, and tenant or context selection
the operator reviews a dedicated runtime access card before continuing
if the operator is already signed in, access is not granted automatically; an explicit confirmation click is required before the authorization callback completes

The Portal also implements the OAuth 2.0 Device Authorization Grant (RFC 8628) for AI agents and CLI tools:

an agent initiates a session and receives a short user code and a verification URL
the operator opens the verification URL, signs in if needed, and approves or denies the agent's request through a dedicated /device page in the Portal
the agent polls a token endpoint and receives credentials once the operator approves
all lifecycle events are recorded in the governance audit trail with a shared session identifier

Tenant And User Administration

Administrators can:

create and manage tenants
activate or deactivate tenants
create and manage platform users
assign users to one or more tenants
manage user roles and administrative scope using area-specific roles
set user passwords and optionally require a password change at next logon

The role model has three tiers. Legacy global roles (SUPER_ADMIN, GLOBAL_READONLY) provide broad cross-tenant access. Global area roles (GLOBAL_<AREA>_READ/MANAGE) give least-privilege cross-tenant access to a single area, filling the gap between full super-admin and tenant-scoped roles. Tenant-scoped area roles (<AREA>_READ/MANAGE) restrict access to one area within a specific tenant. Legacy broad tenant roles (TENANT_ADMIN, TENANT_READONLY) remain supported for backward compatibility. The Security area is intentionally excluded from all read-only legacy roles.

API Onboarding

The Portal supports onboarding downstream APIs from OpenAPI and SOAP/WSDL definitions by:

importing from a URL
importing from raw document content
storing imported API metadata
browsing operations and schemas
inspecting protocol-aware operation metadata, request/response schemas, SOAP headers, and fault shapes
reviewing protocol-specific details such as SOAP actions, bindings, and headers
renaming imported API records after import
refreshing legacy OpenAPI imports into the current protocol-aware model
deleting obsolete imported API definitions

When a downstream API evolves, the Portal supports version tracking through API families:

importing a new version of an existing API alongside the original record without disrupting existing mappings
organizing related imports into a named family with per-revision version labels
reviewing all revisions in a family through an expandable panel on each API card
designating which revision is the current version of the family
comparing any two revisions through a compatibility view that highlights added, removed, and changed operations and identifies breaking changes
delete protection that prevents removing an API definition that any mapping version depends on

This is the starting point for building AI-facing tools from existing APIs.

Mapping Lifecycle Management

The Portal supports the full functional lifecycle of mappings:

create mapping proposals from imported APIs, optionally with reference attachments to guide immediate enrichment
edit mapping metadata and endpoint definitions while the mapping is in an editable status (Draft or Proposed)
maintain mapping versions
approve mappings
publish mappings
deprecate mappings
revert to earlier versions
cancel a pending version (Draft, Proposed, Under review, or Approved) and fall back to the previous published version
delete mappings

When the source API belongs to a version family, the Portal supports creating a new mapping version targeted at a specific API revision:

a target API version selector appears in the new-version panel showing all revisions in the family
the platform seeds the new draft's endpoints from the selected API version, preserving field mappings and endpoint IDs where operations match by key
operations that no longer match receive new IDs, which surfaces as toolset selection orphaning that administrators can review before publishing
the target API version is recorded on the mapping version as metadata and does not affect runtime execution

Mappings are the core business artifact that translate technical downstream operations into usable AI tools.

LLM Connections

The Portal provides a dedicated area for managing the LLM provider connections that power semantic enrichment.

Administrators can:

create and manage LLM connections for OpenAI-compatible or Azure OpenAI providers
define model profiles within each connection, specifying the exact model, deployment, temperature, and timeout
assign global connections to specific tenants so enrichment jobs can use shared provider resources
set the global default model profile for enrichment jobs that do not specify a model explicitly
configure per-tenant default model overrides so each tenant can use a different LLM model as its default

Global super-admins have access to a Per-Tenant Defaults panel that shows every tenant's current default model in a single searchable grid, with a direct action to update each tenant's assignment without navigating tenant-by-tenant.

Semantic Enrichment

The Portal lets administrators request AI-assisted enrichment for mappings. Functionally, this means the platform can help propose:

mapping names
mapping descriptions
endpoint names
input field name and description suggestions
output field name and description suggestions

Each enrichment request creates a tracked enrichment run. The background pipeline processes the mapping through a chunked LLM strategy, with each LLM call recorded as a child chunk log entry under the run.

While a mapping is being enriched, the mappings workspace shows live chunk progress for that specific mapping.

Enrichment runs and their per-chunk activity are reviewed through dedicated governance pages.

Toolset And Client Application Management

The Portal is where administrators decide how published mappings are exposed to AI callers.

It supports:

creation and management of MCP toolsets
selection of which endpoints are exposed as tools
configuration of toolset-level and endpoint-level schema discovery modes
definition of optional toolset-level default system prompts
configuration of request/response payload logging per toolset and per endpoint
assignment of toolsets to client applications
management of tenant-scoped client applications
definition of optional client-application system prompts
per-assignment prompt composition rules for append or override behavior
management of application API keys for those client applications

This lets the same tenant publish different tool catalogs to different AI consumers.

Toolset exposure now includes explicit MCP schema discovery choices:

Full
Data Structure Only
Lazy

Endpoint-specific overrides can diverge from the toolset default when needed, and the toolset editor highlights the effective mode for each included endpoint so administrators can review the final runtime behavior before saving.

Downstream Security And Secret Management

The Portal includes dedicated administration for downstream execution setup:

target systems
target authentication profiles
tool endpoint authentication bindings
credential workflow definitions
outbound host allowlists
managed secret storage
secret store connection management

Supported downstream authentication strategy types include:

no downstream authentication
passthrough bearer token
API key from secret store
basic authentication from secret store
static bearer token from secret store
client credentials template
token exchange template
SOAP username token
SOAP username token digest
SOAP custom headers
client certificate (mTLS)
workflow-based credential resolution

Credential workflows allow step-based credential orchestration using validated workflow definitions.

Identity And Trust Administration

The Portal provides administration for:

trusted identity providers for runtime caller trust
external identity providers for portal sign-in
claim mapping profiles as a dedicated Security page
external tenant allow-lists
per-tenant external provider configuration
external provider to tenant assignments

This separates human portal authentication concerns from runtime caller trust and authorization concerns.

In the Portal Security navigation these areas now appear as separate entries:

External Identity Providers
Trusted Identity Providers
Claim Mapping Profiles

Governance And Operations

The Portal is also the main operator cockpit for governance and monitoring. It supports:

governance summary dashboards with activity trends and top categories
audit record listing, filtering, and detail inspection
request/response payload review in audit record details when logging is enabled
configuration-write audit visibility for administrative changes across account security, onboarding, mappings, AI settings, sessions, and security setup
runtime call listing
full call trace visualization by correlation ID with per-step timing
enrichment run monitoring with per-chunk LLM activity detail and live progress updates
external audit target management via dedicated Audit Delivery Settings page:
- create, view, edit, enable/disable, and delete operational audit targets
- four target kinds supported: REST Endpoint, SQL Server, PostgreSQL, Syslog
- schema-driven dynamic forms — each kind defines its own parameters, rendered automatically in the UI
- secret references for sensitive configuration values (credentials, bearer tokens, API keys)
- SQL Server and PostgreSQL use a separate base connection string plus Username Secret and Password Secret references — credentials are never embedded in the stored connection string
- Auto-create Schema option lets the platform generate the required audit table DDL; the CREATE TABLE script is also available in the View panel for manual provisioning
- Outbound Host Allowlist enforcement for REST endpoint URLs — the Jobs Worker rejects deliveries to unregistered hosts
- Direct and Queue test modes for verifying target connectivity and end-to-end delivery pipeline
- global or tenant-scoped delivery; tenant-scoped targets limited to 3 per tenant
- per-target health state, pending count, and failed count in the grid; full statistics in the View panel
- deployment-managed (compliance) targets visible as read-only; UI-managed (operational) targets fully editable
- global audit target write actions restricted to global administrators; tenant-scoped users see but cannot modify global targets
audit delivery health summary on the Monitoring Dashboard with a link to full settings
health visibility
platform notifications with real-time updates

Protocols And Interaction Patterns

From a functional perspective, the Portal uses:

REST/JSON for administrative APIs
JWT-based authenticated sessions for portal users
cookie-supported browser authentication flows
OIDC Authorization Code + PKCE external login flow with Microsoft Entra ID and Keycloak
SignalR for real-time notifications

Platform Data Store Support

The Portal uses the shared platform database for its administrative and operational data. This shared data model is the source of truth for Portal configuration, governance, and operational records.

Who Uses The Portal

The Portal is designed primarily for:

platform super administrators
tenant administrators
security and operations teams
onboarding and governance operators

It is not the surface intended for AI agents to consume directly. Its main purpose is to prepare, secure, and monitor what the Runtime exposes.

The full platformfunctional reference.