๐Ÿ† Omniagent API Hackathon ยท May 18 โ€“ June 15 โ€” Register now and start building
Migrations

From Per-Session Connections to Omniagent

Migrate from per-session POST /public/connections to the Omniagent model

If you're currently using POST /public/connections (WebRTC) or POST /public/ws-connections (WebSocket) to create sessions, this guide walks you through migrating to the Omniagent model.

Why migrate

With per-session connections, you pass the full configuration โ€” companion, voice, tools, knowledge, provider settings โ€” on every request. With an Omniagent, you define that configuration once and create sessions with a minimal call. Benefits:

  • Less code per session โ€” one field (channelType) instead of repeating the full config
  • Consistency โ€” same agent across WebRTC, WebSocket, and SIP
  • Update once โ€” change the voice or swap a tool, every channel picks it up
  • Memory across channels โ€” the same user can talk to the same agent on web and phone

The per-session endpoints (POST /public/connections and POST /public/ws-connections) are not deprecated. They still work and are available for prototyping or one-off sessions.

Migration steps

Create an Omniagent

Take the fields from your existing connection request and use them to create an agent:

Before โ€” passed on every session:

curl -X POST https://companion-api.napster.com/public/connections \
  -H "X-Api-Key: $NAPSTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "companionId": "comp_abc123",
    "language": "English",
    "functions": ["fn_order_status", "fn_returns"],
    "faqCollections": ["faq_support"],
    "knowledgeBaseId": "kb_product_docs",
    "providerConfig": {
      "voiceId": "alloy",
      "settings": {
        "temperature": 0.7
      }
    }
  }'

After โ€” created once:

curl -X POST https://companion-api.napster.com/public/agents \
  -H "X-Api-Key: $NAPSTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "companionId": "comp_abc123",
    "name": "Support Agent",
    "voiceId": "alloy",
    "language": "English",
    "functions": ["fn_order_status", "fn_returns"],
    "faqCollections": ["faq_support"],
    "knowledgeBaseId": "kb_product_docs",
    "providerSettings": {
      "temperature": 0.7
    }
  }'

Key differences:

  1. voiceId moves from providerConfig.voiceId to a top-level field
  2. providerConfig.settings becomes providerSettings (top-level, flattened)
  3. name is new โ€” an optional label for the agent

Replace session creation calls

Replace your POST /public/connections or POST /public/ws-connections calls with POST /public/agents/{agentId}/connections.

WebRTC โ€” before:

curl -X POST https://companion-api.napster.com/public/connections \
  -H "X-Api-Key: $NAPSTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "companionId": "comp_abc123",
    "functions": ["fn_order_status"],
    "providerConfig": {
      "voiceId": "alloy",
      "settings": { "temperature": 0.7 }
    },
    "externalClientId": "user_12345"
  }'

WebRTC โ€” after:

curl -X POST https://companion-api.napster.com/public/agents/agent_abc123/connections \
  -H "X-Api-Key: $NAPSTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "channelType": "webrtc",
    "externalClientId": "user_12345"
  }'

WebSocket โ€” before:

curl -X POST https://companion-api.napster.com/public/ws-connections \
  -H "X-Api-Key: $NAPSTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "companionId": "comp_abc123",
    "functions": ["fn_order_status"],
    "providerConfig": {
      "voiceId": "alloy",
      "settings": { "temperature": 0.7 }
    },
    "externalClientId": "user_12345"
  }'

WebSocket โ€” after:

curl -X POST https://companion-api.napster.com/public/agents/agent_abc123/connections \
  -H "X-Api-Key: $NAPSTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "channelType": "websocket",
    "externalClientId": "user_12345"
  }'

Both channels use the same endpoint โ€” only channelType differs. The response returns the same token and connection object. Your SDK integration and WebSocket connection code stays the same.

Handle session-specific fields

Some fields from the old connection request are passed per session, not on the agent:

FieldWhere it goes
externalClientIdPass on POST /public/agents/{agentId}/connections
externalClientProfilePass on POST /public/agents/{agentId}/connections
tagsSet on the agent (POST/PATCH /public/agents/{agentId}) or per-session (POST /public/agents/{agentId}/connections)
disableIdleTimeoutSet on the agent (POST/PATCH /public/agents/{agentId})
providerConfig.useGreenVideoSet on the channel config (PUT /public/agents/{agentId}/channels/{channelType}) as useGreenVideo

Field mapping

Per-session connection field
Agent field
companionIdcompanionId
providerConfig.voiceIdvoiceId (top-level)
providerConfig.settings.*providerSettings.* (top-level)
languagelanguage
functionsfunctions
faqCollectionsfaqCollections
knowledgeBaseIdknowledgeBaseId

On this page