TL;DR - Setup Requirements

To enable Champion for a customer, you must complete these 5 steps:

1. Create Account - Create a Champion account for the customer, starts unverified, customer must verify and domain must match customer email
2. Create Champion Token Exchange Application - Create a token exchange application for embedding the chatbot
3. Integrate Token Exchange into Host Application - Implement token exchange in the host application backend
4. Create Host User Delegate OAuth Application - Create OAuth application in the host system for user delegation ⚠️ Required for agentic capabilities
5. Configure Champion Tool Auth - Configure Champion with OAuth credentials from the host application ⚠️ Required for agentic capabilities

Critical: Steps 4-5 are essential for agentic capabilities. Without these, Champions will not be able to access APIs of the host system or act on behalf of users. The chatbot will function for basic conversations, but Champions cannot perform actions or retrieve data from the host system.

Skip to: Account Setup | Embedded Champion | Agentic Champion

Table of Contents

1. Account Setup
2. Embedded Champion
3. Agentic Champion
4. Enabling Champions (Admin)
5. Chatbot Champions (End User)

Account Setup

Step 1: Create Account

BECAUSE

Accounts are the main tenancy boundary for customers within the Champion platform. All objects and configurations we create are tied to an account for security reasons. This is why the account must be created first and referenced in all follow-up configuration requests.

Think of an account as the top-level container that isolates one customer's data, users, Champions, and configurations from another. Without an account, there is no context for where to store or retrieve any Champion-related data.

HOW

As a privileged user of the Champion Web Experience OR through the REST API with the elevated product service account.

WHERE

• Champion Web Experience (Account Management area)
• Champion REST API

API Example: Create Account

POST https://api.champion.ai/champion/api/management/accounts
Authorization: Bearer <product-service-account-token>
Content-Type: application/json

{
  "name": "Acme Manufacturing",
  "website": "https://acme-manufacturing.com",
  "overview": "Leading manufacturer of industrial widgets",
  "manufacturingModel": "Discrete manufacturing with JIT principles",
  "strategicPriorities": "Reduce waste, improve OEE, digital transformation",
  "systemAndTools": "Adaptive, Redzone Connected Worker",
  "domains": ["acme-manufacturing.com", "acme.io"]
}

Response (201 Created):

{
  "uuid": "00000000-0000-0000-0000-000000000001",
  "name": "Acme Manufacturing",
  "website": "https://acme-manufacturing.com",
  "overview": "Leading manufacturer of industrial widgets",
  "verificationStatus": "unverified",
  "createdAt": "2024-01-15T10:30:00Z",
  "updatedAt": "2024-01-15T10:30:00Z"
}

Important: Save the uuid - this accountUUID is required for ALL subsequent API calls.

Post-Creation Requirements

After creating an account via API, the customer must still complete these steps:

1. Login and Verify Account - Customer logs in to Champion Web Experience (CWE) at https://app.champion.ai to complete account verification
2. Accept Terms of Service - Customer must accept Champion's terms of service in CWE
3. Enable Champion - Ensure Champion is marked as enabled for the account in CWE

📘

Critical - Domain Matching: The domains array provided during account creation must include the customer's actual email domain. If the domain doesn't match when the customer logs into Champion Web Experience (CWE), a "duplicate" account will be created and linked to their actual email domain, and all preemptive configuration will be invalid and linked to the wrong account. To avoid issues, ensure the domains array includes all email domains the customer's users will use.

Example: If you create an account with domains: ["acme-manufacturing.com"] but users have @acme.io email addresses, a "duplicate" account will be created when they log in to the Champion Web Experience for account verification.

API Example: Get Account

GET https://api.champion.ai/champion/api/management/accounts/{accountUUID}
Authorization: Bearer <token>

API Example: Update Account

PATCH https://api.champion.ai/champion/api/management/accounts/{accountUUID}
Authorization: Bearer <token>
Content-Type: application/json

{
  "name": "Acme Manufacturing Inc.",
  "strategicPriorities": "Updated priorities for Q2"
}

API Example: Deactivate Account (Soft Delete)

DELETE https://api.champion.ai/champion/api/management/accounts/{accountUUID}
Authorization: Bearer <token>

Response: 204 No Content

Embedded Champion

This section covers embedding the Champion chatbot within a host application using token exchange.

Why Token Exchange is Required

When a user accesses the Champion chatbot embedded within a host application, they need a Champion-issued token to securely communicate with Champion Server. However, the user only has a Host token (from logging into the host application).

Token exchange solves this by using the Host Backend as a trusted authorizer to exchange the Host token for a Champion token. This ensures:

1. Secure Authentication - Champion Server trusts the Host Backend to verify user identity
2. User Context - Champion token is scoped to the specific user, account, and organization
3. No Duplicate Login - Users don't need separate Champion credentials
4. Backend Security - Token exchange happens server-to-server using clientId and clientSecret

Token Exchange Conceptual Flow

sequenceDiagram
    participant User as User in Host Application
    participant Chatbot as Embedded Champion Chatbot
    participant HostBackend as Host Backend
    participant ChampionServer as Champion Server

    User->>Chatbot: Opens chatbot (has Host token)
    Chatbot->>HostBackend: Request Champion token<br/>(send Host token)
    HostBackend->>HostBackend: Validate Host token
    HostBackend->>ChampionServer: Token exchange request<br/>(userId, clientId, clientSecret)
    ChampionServer->>ChampionServer: Verify credentials & create Champion token
    ChampionServer->>HostBackend: Return Champion token
    HostBackend->>Chatbot: Return Champion token
    Chatbot->>Chatbot: Store Champion token

    Note over Chatbot,ChampionServer: Chatbot can now communicate with Champion Server

    Chatbot->>ChampionServer: API request with Champion token
    ChampionServer->>ChampionServer: Validate Champion token
    ChampionServer->>Chatbot: Return response
    Chatbot->>User: Display results

This flow ensures that:

• Users authenticate once with the host application
• Host Backend acts as a trusted intermediary
• Champion tokens are issued only after Host Backend validates the user
• All chatbot-to-Champion Server communication is secured with Champion-issued tokens
• Token exchange credentials (clientId, clientSecret) never leave the Host Backend

📘

Shared Responsibility Security Model: Token exchange is based on a shared responsibility model. Champion entrusts the Host Backend to securely verify that the host user is who they say they are before making the token exchange request. The Host Backend MUST properly validate the Host token and confirm the user's identity before calling Champion's token exchange endpoint. Champion Server will issue a Champion token based on the userId provided by the Host Backend, trusting that the Host Backend has performed proper authentication and authorization checks.

Step 2: Create Token Exchange Application

BECAUSE

The token exchange application enables secure embedding of the Champion chatbot within a host application instance.

When creating a token-exchange application, you provide:

• A unique organizationId within the account (e.g., an EU number)
• A productId identifying the host application type (e.g., "redzone", "adaptive")

The organizationId represents an installation of the host application and serves as a sub-tenant of the account. This is critical because:

1. Communication Link: It establishes the connection between the Champion chatbot and the host application
2. User Authorization: The host backend uses the Champion clientId and clientSecret for the token exchange flow:
   • Host user's token is sent to host backend and verified
   • Host backend sends userId, clientId, and clientSecret to Champion
   • Champion returns a Champion token scoped to the account, organization, and user
3. Security Isolation: Since the application contains both accountUUID and organizationId, all Champion tokens are isolated to the correct tenant

HOW

As a privileged user of the Champion Web Experience (Applications area) OR through the REST API with the elevated product service account.

WHERE

• Champion Web Experience -> Applications
• Champion REST API

API Example: Create Token Exchange Application

POST https://api.champion.ai/champion/api/management/accounts/{accountUUID}/applications
Authorization: Bearer <token>
Content-Type: application/json

{
  "type": "token-exchange",
  "organizationId": "EU-12345",
  "organizationName": "Acme Chicago Plant",
  "productId": "redzone",
  "name": "Acme Chicago Plant - Redzone Integration",
  "description": "Token exchange application for Redzone integration at Chicago facility"
}

Response (201 Created):

{
  "uuid": "00000000-0000-0000-0000-000000000002",
  "accountUUID": "00000000-0000-0000-0000-000000000001",
  "type": "token-exchange",
  "organizationId": "EU-12345",
  "organizationName": "Acme Chicago Plant",
  "productId": "redzone",
  "name": "Acme Chicago Plant - Redzone Integration",
  "description": "Token exchange application for Redzone integration at Chicago facility",
  "clientId": "champion_te_abc123xyz",
  "clientSecret": "secret_xxxxxxxxxxxxxxxxxxxxxxxx",
  "status": "active",
  "createdAt": "2024-01-15T10:35:00Z"
}

Critical: The clientSecret is returned ONLY on creation. Store it securely - it is needed for Step 3. The clientId can be retrieved later if needed.

API Example: List Applications

GET https://api.champion.ai/champion/api/management/accounts/{accountUUID}/applications?applicationType=token-exchange&page=0&perPage=20
Authorization: Bearer <token>

API Example: Get Application Details

GET https://api.champion.ai/champion/api/management/accounts/{accountUUID}/applications/{applicationUUID}
Authorization: Bearer <token>

API Example: Update Application

PATCH https://api.champion.ai/champion/api/management/accounts/{accountUUID}/applications/{applicationUUID}
Authorization: Bearer <token>
Content-Type: application/json

{
  "name": "Acme Chicago Plant - Host Application (Updated)",
  "description": "Updated description"
}

API Example: Deactivate Application (Soft Delete)

DELETE https://api.champion.ai/champion/api/management/accounts/{accountUUID}/applications/{applicationUUID}
Authorization: Bearer <token>

Response: 204 No Content

Note: This is a soft delete. The application can be reactivated.

API Example: Reactivate Application

POST https://api.champion.ai/champion/api/management/accounts/{accountUUID}/applications/{applicationUUID}/reactivate
Authorization: Bearer <token>

API Example: Hard Delete Application (Permanent)

DELETE https://api.champion.ai/champion/api/management/accounts/{accountUUID}/applications/{applicationUUID}/hard-delete
Authorization: Bearer <token>

Response: 204 No Content

Warning: This permanently deletes the application from Auth0 and marks it as deleted in the database. This action is IRREVERSIBLE.

Step 3: Configure Host Token Exchange

BECAUSE

The host application must implement the token exchange mechanism to obtain Champion tokens on behalf of its users.

As mentioned in Step 2, the host application needs the organizationId, clientId, and clientSecret to:

1. Receive the host user's authentication token
2. Validate the token to prove the user's identity
3. Use back-channel authentication to Champion server to request a Champion token
4. Return the Champion token to the embedded chatbot

This ensures that Champion can securely identify which user is making requests and associate their actions with the correct account and organization.

HOW

This step is performed in the external host system. The implementation varies by host but generally follows this pattern:

1. Host provides an endpoint (configured in Champion Chatbot integration code)
2. Embedded chatbot requests a Champion token, providing the host user's token
3. Host backend validates the host user's token
4. Host backend calls Champion's token exchange endpoint with:
   • userId (from validated host token)
   • clientId (from Step 2)
   • clientSecret (from Step 2)
5. Champion returns a scoped token for use in chatbot communications

WHERE

• External Host System (outside Champion's control)

Conceptual Flow

sequenceDiagram
    participant Chatbot as Chatbot in Host App
    participant Host as Host Backend
    participant Champion as Champion Server

    Chatbot->>Host: host_token
    Host->>Host: validate token
    Host->>Champion: token_exchange<br/>(userId, clientId, clientSecret)
    Champion->>Host: champion_token
    Host->>Chatbot: champion_token

Note: Specific implementation details are contingent upon the individual external host application and are outside the scope of Champion documentation.

Agentic Champion

This section covers enabling Champions to make API requests on behalf of authenticated users through OAuth2 delegation.

📘

Critical for Agentic Capabilities: The steps in this section are essential for Champions to access APIs of the host system and act on behalf of users. Without completing these steps, Champions will not have the ability to retrieve data or perform actions in the host system. The chatbot will function for basic conversations, but agentic capabilities will be unavailable.

Why User Delegation is Required

Champions need to access host system APIs on behalf of authenticated users to retrieve data and perform actions. This requires an OAuth2 authorization code flow with PKCE (code verifier) that allows:

1. User Authentication - User proves their identity to the host system
2. User Authorization - User grants Champion permission to act on their behalf
3. Token Exchange - Champion receives access tokens to make API requests as the user
4. Agentic Actions - Champion agents can now call Host Backend APIs with user context

OAuth2 User Delegation Flow

sequenceDiagram
    participant User as User in Champion Chatbot
    participant ChampionServer as Champion Server
    participant ChampionAgent as A Champion
    participant HostAuth as Host Auth Provider
    participant HostAPI as Host Backend API

    User->>ChampionAgent: Request action requiring host data
    ChampionAgent->>ChampionAgent: Attempt tool call, needs auth
    ChampionAgent->>ChampionServer: Request user delegation
    ChampionServer->>User: Redirect to authorization URL
    User->>HostAuth: Login with credentials
    HostAuth->>HostAuth: Verify login
    User->>HostAuth: Authorize Champion app
    HostAuth->>ChampionServer: Return authorization code
    ChampionServer->>HostAuth: Exchange code for tokens<br/>(access token + refresh token)
    HostAuth->>ChampionServer: Return access token & refresh token
    ChampionServer->>ChampionServer: Securely store tokens for user
    ChampionServer->>User: Success - delegation complete

    Note over ChampionAgent,HostAPI: A Champion can now act on behalf of user

    ChampionAgent->>HostAPI: API request with user's access token
    HostAPI->>HostAPI: Validate token & user permissions
    HostAPI->>ChampionAgent: Return user-specific data
    ChampionAgent->>User: Display results

This flow ensures that:

• Champion never sees the user's host system password
• User explicitly grants permission for Champion to act on their behalf
• All API requests to the host system are made with the user's identity and permissions
• Champion agents can retrieve data and perform actions as if the user themselves made the request

Step 4: Create Host OAuth Application

BECAUSE

User-delegation (OAuth2 code verifier flow) allows Champion to make API requests on behalf of authenticated users.

When a Champion agent needs to interact with the host system's APIs (e.g., to fetch data or perform actions), it needs the user's permission. The OAuth2 code verifier (PKCE) flow:

1. Prompts the user to authenticate with the host system
2. Asks the user to grant consent for Champion to act on their behalf
3. Provides Champion with tokens to make authorized API calls

Without this OAuth configuration, Champion cannot perform agentic actions that require user-specific permissions on the host system.

HOW

As a privileged user of the Host Application, or through the Host's API if available, create an OAuth2 application/client capable of supporting the authorization code flow with PKCE.

WHERE

• External Host System (outside Champion's control)

Requirements for the Host OAuth Application

1. Flow Type: Authorization Code with PKCE (code verifier)
2. Redirect URI: Champion's callback URL (provided during Champion configuration)
3. Scopes: Define what permissions Champion can request on behalf of users
4. Refresh Tokens: Enable refresh tokens for extended session duration

Note: This step is outside the scope of Champion documentation as it's contingent upon the specific external Host application's OAuth implementation.

Step 5: Configure Champion with Host OAuth

BECAUSE

Champion needs to know the host's authorization endpoint to act on behalf of users.

This configuration tells Champion:

• Scope: Whether this OAuth config is account-wide or organization-specific
  • Critical when multiple organizations exist within an account
  • Enables Champion to direct users to the correct host instance for authorization
• OAuth Details: Client ID, client secret, endpoints, and scopes

Multi-tenant Support: Champion supports global-scope auth configurations for hosts with a single auth endpoint for all implementations. In this case, no additional per-organization auth configuration is required.

HOW

As a privileged user of the Champion Web Experience (Tool Configuration area) OR through the REST API with the elevated product service account.

WHERE

• Champion Web Experience -> Tool Configuration
• Champion REST API

API Example: Create Tool Auth Config (OAuth2 Delegation)

POST https://api.champion.ai/champion/api/management/accounts/{accountUUID}/tools/auth
Authorization: Bearer <token>
Content-Type: application/json

{
  "toolUUID": "00000000-0000-0000-0000-000000000003",
  "scope": "organization",
  "organizationId": "EU-12345",
  "displayName": "Host Application OAuth - Chicago Plant",
  "description": "OAuth configuration for host application API access at Chicago facility",
  "credentials": {
    "type": "oauth2Delegation",
    "clientId": "host_oauth_client_abc123",
    "clientSecret": "host_secret_xxxxxxxx",
    "authorizationEndpoint": "https://auth.example.com/authorize",
    "tokenEndpoint": "https://auth.example.com/oauth/token",
    "scopes": "openid profile email offline_access api.read api.write",
    "audience": "https://api.example.com",
    "issuerUrl": "https://auth.example.com/",
    "successRedirectUrl": "https://champion.ai/auth/callback/success",
    "errorRedirectUrl": "https://champion.ai/auth/callback/error"
  }
}

Response (201 Created):

{
  "uuid": "00000000-0000-0000-0000-000000000004",
  "accountUUID": "00000000-0000-0000-0000-000000000001",
  "toolUUID": "00000000-0000-0000-0000-000000000003",
  "scope": "organization",
  "organizationId": "EU-12345",
  "displayName": "Host Application OAuth - Chicago Plant",
  "authMethod": "oauth2Delegation",
  "createdAt": "2024-01-15T10:45:00Z",
  "updatedAt": "2024-01-15T10:45:00Z"
}

API Example: List Tool Auth Configs

GET https://api.champion.ai/champion/api/management/accounts/{accountUUID}/tools/auth?scope=organization&organizationId=EU-12345
Authorization: Bearer <token>

API Example: Get Tool Auth Config

GET https://api.champion.ai/champion/api/management/accounts/{accountUUID}/tools/auth/{configUUID}
Authorization: Bearer <token>

API Example: Update Tool Auth Config

PUT https://api.champion.ai/champion/api/management/accounts/{accountUUID}/tools/auth/{configUUID}
Authorization: Bearer <token>
Content-Type: application/json

{
  "displayName": "Host Application OAuth - Chicago Plant (Updated)",
  "description": "Updated description",
  "credentials": {
    "type": "oauth2Delegation",
    "clientId": "host_oauth_client_abc123",
    "clientSecret": "new_host_secret_xxxxxxxx",
    "authorizationEndpoint": "https://auth.example.com/authorize",
    "tokenEndpoint": "https://auth.example.com/oauth/token",
    "scopes": "openid profile email offline_access api.read api.write",
    "audience": "https://api.example.com"
  }
}

API Example: Delete Tool Auth Config

DELETE https://api.champion.ai/champion/api/management/accounts/{accountUUID}/tools/auth/{configUUID}
Authorization: Bearer <token>

Response: 204 No Content

API Example: Associate Tool with Auth Config (if not done during creation)

POST https://api.champion.ai/champion/api/management/accounts/{accountUUID}/tools/auth/{configUUID}/tools/{toolUUID}
Authorization: Bearer <token>

Response: 204 No Content

API Example: Dissociate Tool from Auth Config

DELETE https://api.champion.ai/champion/api/management/accounts/{accountUUID}/tools/auth/{configUUID}/tools/{toolUUID}
Authorization: Bearer <token>

Response: 204 No Content

Step 6: Configure Champion with Host API Destination

BECAUSE

Some agentic tools require service configuration to know where to direct API requests.

For tools like the ERP API, Champion needs to know:

• The URL of the specific ERP instance
• Any instance-specific configuration (headers, paths, etc.)

This ensures that when a Champion (our Agent Supervisors that match manufacturing personas) uses a tool, it knows exactly where to send its API requests for data retrieval and updates.

Example: The ERP API tool requires the URL of the ERP instance so that any Champion using this tool can route requests correctly.

HOW

As a privileged user of the Champion Web Experience (Tool Configuration area) OR through the REST API with the elevated product service account.

WHERE

• Champion Web Experience -> Tool Configuration
• Champion REST API

Note on Configuration Payloads: The structure of the config object varies depending on how each tool is configured. Each tool defines its own required configuration fields based on its specific integration needs. The examples below show a typical ERP API tool configuration, but your tool may require different fields. Consult the tool's documentation or Champion support for the specific configuration schema required by your tool.

API Example: Create Tool Service Config

POST https://api.champion.ai/champion/api/management/accounts/{accountUUID}/tools/configs
Authorization: Bearer <token>
Content-Type: application/json

{
  "toolUUID": "00000000-0000-0000-0000-000000000005",
  "scope": "organization",
  "organizationId": "EU-12345",
  "displayName": "ERP API - Chicago Plant",
  "description": "ERP API configuration for Chicago facility",
  "config": {
    "baseUrl": "https://erp-chicago.acme-manufacturing.com/api/v1",
    "environment": "production",
    "timeout": 30000,
    "customHeaders": {
      "X-ERP-Client": "100"
    }
  }
}

Response (201 Created):

{
  "uuid": "00000000-0000-0000-0000-000000000006",
  "accountUUID": "00000000-0000-0000-0000-000000000001",
  "toolUUID": "00000000-0000-0000-0000-000000000005",
  "scope": "organization",
  "organizationId": "EU-12345",
  "displayName": "ERP API - Chicago Plant",
  "description": "ERP API configuration for Chicago facility",
  "config": {
    "baseUrl": "https://erp-chicago.acme-manufacturing.com/api/v1",
    "environment": "production",
    "timeout": 30000,
    "customHeaders": {
      "X-ERP-Client": "100"
    }
  },
  "createdAt": "2024-01-15T10:50:00Z",
  "updatedAt": "2024-01-15T10:50:00Z"
}

API Example: List Tool Service Configs

GET https://api.champion.ai/champion/api/management/accounts/{accountUUID}/tools/configs?scope=organization&organizationId=EU-12345
Authorization: Bearer <token>

API Example: Get Tool Service Config

GET https://api.champion.ai/champion/api/management/accounts/{accountUUID}/tools/configs/{configUUID}
Authorization: Bearer <token>

API Example: Update Tool Service Config

PUT https://api.champion.ai/champion/api/management/accounts/{accountUUID}/tools/configs/{configUUID}
Authorization: Bearer <token>
Content-Type: application/json

{
  "displayName": "ERP API - Chicago Plant (Production)",
  "description": "Updated configuration",
  "config": {
    "baseUrl": "https://erp-chicago.acme-manufacturing.com/api/v2",
    "environment": "production",
    "timeout": 45000,
    "customHeaders": {
      "X-ERP-Client": "100",
      "X-Custom-Header": "value"
    }
  }
}

API Example: Delete Tool Service Config

DELETE https://api.champion.ai/champion/api/management/accounts/{accountUUID}/tools/configs/{configUUID}
Authorization: Bearer <token>

Response: 204 No Content

Enabling Champions (Admin)

BECAUSE

Champions represent manufacturing personas, and Champion AI continuously develops new Champions to empower various manufacturing staff.

However, not all Champions are relevant to every customer. Account administrators control which Champions are available to their users by:

1. Reviewing available Champions
2. Enabling those that match their organization's needs

This ensures users only see relevant Champions and administrators maintain control over which AI capabilities are exposed.

Prerequisites

1. Account must be verified via DNS TXT record verification
   • See: https://docs.champion.ai/docs/account-creation#domain-ownership-verification
2. User must be an account administrator

HOW

1. Log in to Champion Web Experience
2. Navigate to Champions section
3. Browse available Champions
4. Enable desired Champions for end users

WHERE

• Champion Web Experience -> Champions

For More Details: See the Configuring Champions guide for detailed information about Champion configuration options, approval workflows, and best practices for enabling Champions for your organization.

Chatbot Champions (End User)

User Experience Overview

Opening the Chatbot

Once the chatbot is embedded and a user has authenticated:

1. User opens the expanded view of the Chatbot
2. User sees "My Champions" section
3. User can select zero or more Champions to pin to their sidebar

Intelligent Routing

If no Champion is directly engaged:

• Champion uses intelligent routing to direct the user's inquiry to the most applicable Champion
• The routing considers the question content, available Champions, and user context

If no Champions are enabled at the account level:

• Champion answers user prompts from the Host Application's knowledgebase
• Basic conversational AI without specialized agentic capabilities

User Linking (Access Grants)

BECAUSE Champions need permission to act on behalf of users:

When engaging with a Champion that needs to make an agentic request requiring authentication:

1. User is prompted to "Grant Access to Champion"
2. User authenticates with the host system (OAuth flow from Steps 4-5)
3. Champion receives tokens to make authenticated requests on behalf of the user

Grant Duration:

• The access grant is valid for the duration of the host application's refresh token
• Users need to renew grants periodically
• Champion does not dictate this duration - it honors the refresh duration of the external system

Example User Flow

User: "What's the inventory status for widget ABC-123?"

[If Inventory Optimization Champion is engaged and user hasn't granted access]

Champion: "I'd like to check your inventory data. To do this, I need
          permission to access your ERP system on your behalf.

          [Grant Access to Champion]"

[User clicks Grant Access, completes OAuth flow]

Champion: "Thanks! Let me check that for you...

          Widget ABC-123 current inventory:
          - On Hand: 1,234 units
          - On Order: 500 units
          - Reorder Point: 800 units
          - Status: Healthy stock levels

          Would you like me to analyze the demand forecast for this item?"

For More Details: See the Chatbot Features guide for comprehensive information about the embedded chatbot capabilities, including how to interact directly with Champions, conversation management, My Threads, Champion summaries, and more.

Quick Reference: API Endpoints

Account Management

Applications

Tool Auth Configurations

Tool Service Configurations

Glossary