Backend Profile Data Model

Overview

A Backend Profile is a configuration record that defines how the API platform connects to, authenticates with, and interacts with a specific backend service. Each profile aggregates all the necessary parameters for the platform runtime to manage outbound traffic to a single backend implementation, acting as a comprehensive blueprint for the connection.

This includes:

• The backend's base URL and specific health check endpoints.
• Authentication credentials and mechanisms, such as API keys, OAuth 2.0, or mTLS.
• Network parameters like connection timeouts and retry strategies.
• Routing logic, including priority and weight for traffic distribution.
• SOAP-specific settings for integrating with WSDL-based services.

API publishers create and manage backend profiles to abstract backend connection details away from the API configuration itself. The platform runtime consumes these profiles to route incoming API consumer requests to the appropriate backend.

How It Works

The Backend Profile data model is central to the platform's routing and security architecture.

Data Flow and Security

When an API publisher defines a Backend Profile, the configuration is persisted in the platform's database. Sensitive data, such as passwords, tokens, and private keys, are stored within a single, encrypted credentials map.

The data flow for retrieving and using a profile is as follows:

flowchart TD
    subgraph API Platform
        A[Admin API Read Request] --> B{Database};
        B -- Fetches encrypted record --> C[Credentials Decryption];
        C -- Provides decrypted profile to runtime --> D{Runtime};
        A -- Returns profile metadata (NO secrets) --> E[API Publisher];
    end

    subgraph Backend Service
        F[Backend Endpoint]
    end

    D -- Uses profile to connect and authenticate --> F;

1. A platform component, such as the runtime processing a consumer request, needs to connect to a backend.
2. It retrieves the corresponding BackendProfileRecord from the database.
3. A dedicated internal cipher component decrypts the credentials map for use in the outbound request.
4. The runtime uses the decrypted credentials and other profile settings (e.g., endpointUrl, connectionTimeoutMs) to establish a connection.

Authentication and mTLS

The profile separates application-layer authentication (authType) from transport-layer security (mtlsEnabled). This means you can enable mutual TLS for a secure transport channel independently of whether the backend requires, for example, an OAuth bearer token for application-level authorization.

Backend Profile Fields

A BackendProfileRecord contains the following fields:

OAuth2ClientAuth Object

This object specifies how the platform authenticates itself to the backend's OAuth 2.0 token endpoint.

ExtraHeader Object

Defines a static, non-secret header to be added to all outbound requests using this profile.

OAuth2ExtraParam Object

Defines an extra parameter to be included in the application/x-www-form-urlencoded body of a request to an OAuth 2.0 token endpoint. This is used alongside standard parameters like grant_type, client_id, and scope.

Credentials Map Structure

The credentials map holds all sensitive data for a backend profile. It is decrypted at runtime and is never exposed via the Admin API. The structure of this map is defined by a platform-wide standard.

Default Behaviors

The system has built-in defaults to ensure a valid configuration:

• If a BackendProfileRecord is created without an oauth2ClientAuth object, the system automatically provides a default configuration where the method is client_secret_post.
• Within the OAuth2ClientAuth object, if the method field is null or blank, it also defaults to client_secret_post.

All SOAP-to-REST docs