September 29, 2026

Refresh MCP tokens mid-session

When a per-user MCP server's access token is about to expire, you can now send a fresh one without ending the session. Send set_settings with mcp.authorizations from your client — the agent uses the new token from its next call to that server.

{
  "type": "set_settings",
  "data": {
    "mcp": {
      "authorizations": [
        {
          "mcp_server_id": "crm",
          "token": "ya29.a0AfH6_refreshed..."
        }
      ]
    }
  }
}

See MCP Servers — Refreshing a token mid-session.

Cascade architecture: choose each model

Cascade is a new architecture for API keys. Instead of one realtime model, speech recognition, the language model, and the voice run as separate stages, and you choose the provider for each:

Azure OpenAI stages can run on Napster's managed infrastructure; Anthropic and OpenAI stages use your own API key. Cascade also unlocks puppeteer mode. Some features work differently on Cascade — for example, MCP servers aren't supported.

See Create an API key — Architectures and Cascade architecture.

Bring your Microsoft Foundry agent

If you've built an agent on Microsoft Foundry, the Napster API can now give it a face. Create an API key on the Other architecture with the Microsoft Foundry platform, and every Omniagent you create with that key runs your Foundry agent — its instructions, model, tools, and knowledge stay in Foundry. Digital twins and the SIP and VoIP channels aren't supported on Foundry keys yet.

Microsoft Foundry support on the Napster API is not enabled by default. Contact us to turn it on for your Napster organization.

See Connect a Microsoft Foundry agent.

Puppeteer mode: the agent speaks your lines

A new mode setting controls how the agent speaks. conversation is the default. In puppeteer mode, the agent speaks only the lines your client sends — use it for scripted presentations, guided tours, or when your own system decides every line.

Set mode on the agent, or per session on POST /public/connections and POST /public/ws-connections:

curl -X PATCH https://companion-api.napster.com/public/agents/agent_abc123 \
  -H "X-Api-Key: $NAPSTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "mode": "puppeteer"
  }'

Then send each line with the new talk command over the session's data channel, and follow it with talk_state_changed events, which carry your talkId back as talk_id. Puppeteer mode requires an API key that uses the Cascade architecture.

See Configuration — Mode and Client commands — talk.

Companion webhooks

Webhooks now also fire for companions: companion.created, companion.updated, and companion.deleted. Use them to react when a companion you created finishes generating, instead of polling its status. Each status change while it generates arrives as companion.updated, from generationCompleted through readyToUse to completed. Companion events cover the companions your project owns, not the Napster stock catalog.

Subscribe to the new events on your webhook in the dashboard under Webhooks. Session webhooks (session.started and session.closed) work as before.

Webhooks also have their own guide now, covering setup, payloads, signature verification, and retries. See Webhooks.

Route SIP calls to different teams

Human handoff on SIP telephony can now send callers to different extensions depending on what they need. Add routes to the SIP channel config — up to 10, each an extension with a purpose — and the agent transfers to the route whose purpose clearly matches the caller's need. Otherwise, the call goes to transferExtension, which is now required when handoff is enabled or routes are set.

curl -X PUT https://companion-api.napster.com/public/agents/agent_abc123/channels/sip \
  -H "X-Api-Key: $NAPSTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "humanHandoff": {
      "enabled": true,
      "transferExtension": "200",
      "routes": [
        {
          "extension": "210",
          "purpose": "Billing questions, invoices, and refunds"
        },
        {
          "extension": "220",
          "purpose": "Technical support for devices and connectivity"
        }
      ]
    }
  }'

See SIP — Routing to different teams.

End a live session from your backend

You can now close a running session with DELETE /public/connections/{connectionId}, using the connection.id you received when you opened it. The session ends right away and shows up as closed with closeReason: "connection_aborted". It works for webrtc, websocket, and kiosk sessions.

curl -X DELETE https://companion-api.napster.com/public/connections/sess_xyz789 \
  -H "X-Api-Key: $NAPSTER_API_KEY"

See Session configuration — Ending a session.

Delete a session and its data

DELETE /public/sessions/{sessionId} permanently removes a finished session, together with its conversation transcript and the memory stored from it. Use it when an end user asks you to delete their data. Only closed or failed sessions can be deleted.

curl -X DELETE https://companion-api.napster.com/public/sessions/sess_abc123 \
  -H "X-Api-Key: $NAPSTER_API_KEY"

See Sessions — Deleting a session.

Video recordings from audio, and a project-wide list

Recordings can now be generated from an audio track instead of text: the avatar lip-syncs to a voice-over or message you provide. Pass audioUrl (up to 50 MB), or upload the file to the new POST /public/companions/{companionId}/recordings/from-file endpoint (up to 2 MB).

curl -X POST https://companion-api.napster.com/public/companions/comp_abc123/recordings \
  -H "X-Api-Key: $NAPSTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "audioUrl": "https://assets.acme.com/audio/welcome.mp3"
  }'

To list all recordings in your project, use the new GET /public/recordings endpoint.

See Video Recordings.

One FAQ collection per agent

An agent can now have one FAQ collection attached. Passing more than one ID in faqCollections returns a 400 validation error with the message "At most 1 FAQ collection can be attached." The limit applies to agents, channel configs, and connections.

curl -X PATCH https://companion-api.napster.com/public/agents/agent_abc123 \
  -H "X-Api-Key: $NAPSTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "faqCollections": ["faq_support"]
  }'

If you split your Q&A pairs across several collections, merge them into one. See Limits — FAQ collections per agent.

functionMetrics is now functionStates

The per-tool connection record on a session is renamed from functionMetrics to functionStates, and its shape is simpler. It used to be an object keyed by function library ID, with an array of tool entries under each ID. It is now one flat array covering every WebSocket-based tool in the session.

curl https://companion-api.napster.com/public/sessions/sess_abc123 \
  -H "X-Api-Key: $NAPSTER_API_KEY"

{
  "id": "sess_abc123",
  "functionStates": [
    {
      "name": "get_order_status",
      "state": "connected",
      "startedAt": "2026-09-29T10:15:02Z",
      "connectedAt": "2026-09-29T10:15:03Z"
    }
  ]
}

Each entry keeps the same fields — name, state, startedAt, connectedAt, failedAt, canceledAt, and error — so updating your code means reading functionStates and dropping the library-ID level. The field is returned by GET /public/sessions/{sessionId}.

See Sessions — Tool connection states.