Skip to main content

Integrations

Integrations are how your agents connect to external services. Each integration wraps the configuration for one service โ€” its URL, auth, and any secrets โ€” so multiple agents can reuse it without duplicating setup.

Open Integrations in the main menu to see everything connected to your workspace.

Three kinds of integrationsโ€‹

KindUse for
Custom APIAny HTTP API. You define the URL, auth, and the set of actions the agent can call.
MCP serverA Model Context Protocol server. Tools are discovered automatically from the server โ€” you don't define them by hand.
Messaging channelOutbound SMS through Telnyx. Used by send text message actions.

Click + Add integration to add one. Custom API and MCP server open a short configuration flow; messaging channel opens a channel-specific form.

Shared actionsโ€‹

Once an integration is connected, you define shared actions under it โ€” for example, a lookup_invoice API call sitting under a "Billing API" integration. Shared actions live on the integration, so any agent can link them.

When a shared action is linked to an agent, the agent can still override per-agent fields: parameters schema, request body template, conversation phases, max successful calls, and allowed states. The shared action itself owns name, description, URL, method, headers, and output variables.

Agent-specific actionsโ€‹

Not every action belongs under an integration. Static responses, end-call rules, simple handover scripts, and client-side events are usually specific to one agent โ€” there's nothing to share. Create those directly on the agent's Actions tab via Add an agent specific action.

API calls that only one agent will ever make can also live as agent-specific actions if you don't want to set up a full integration first. You can always promote one to a shared action later by creating an integration and recreating the action under it.

Live referencesโ€‹

When you change a shared action โ€” rename an output variable, add a header, change the URL โ€” every agent linking it picks up the new shape immediately. This keeps your API contract in one place: fix it once on the integration and every agent using it stays in sync.

Restore behaviorโ€‹

Restoring an older agent version doesn't roll back the shared actions that version was using. The restored agent uses the current shape of each linked action, which may have changed since the version was last published.

Three checks surface what's changed so you can react:

  • Restore preview. Before you confirm a restore, the preview dialog lists shared actions that have changed since this version was locked, or that have been deleted.
  • Post-restore banner. After restore, the agent's Actions tab shows a banner listing any actions whose shape no longer matches what the restored version expects. Each entry links to the action so you can review prompts or unlink.
  • Publish-time validation. When you publish a version, Stellar blocks publishing if any binding references a deleted or moved shared action, and lists the broken references so you can re-link or remove them.

Next stepsโ€‹