Platform

Integrations

The Integration Hub at /integrations connects AgentSwarms to outside model providers and automation; /mcp connects it to tool servers. Keys are stored server-side and used only by the runtime — they are never sent back to the browser.

The default provider first

If the operator running this instance has configured a shared OpenRouter key, you don't need any integration to start — every account can use it with no setup. Connecting your own provider key routes calls to your own account/billing instead, and unlocks providers the shared key doesn't cover.

LLM providers (bring your own key)

The LLM Providers tab is a set of key forms, one per provider, each with the fields that provider actually needs:

Direct API keys — OpenAI (with optional org ID), Anthropic (with API version), Google Gemini, Grok (xAI), Groq, OpenRouter, NVIDIA, Qwen (DashScope). Most accept an optional custom base URL.
Cloud platforms — AWS Bedrock, Google Vertex AI, Azure OpenAI (endpoint + deployment), and OCI Generative AI, with their platform-specific credential fields.
Self-hosted — custom Ollama endpoints and OpenAI-compatible vLLM servers.

Once connected, a provider becomes selectable in the Agent Builder and in swarm node inspectors. Some providers' models don't support tool calling — the builder warns you when an agent with tools is pointed at one.

LLM Gateway

The LLM Gateway tab points the platform at your own OpenAI-compatible gateway — LiteLLM and similar. You give it a base URL and a key, and choose one of two routing modes.

Mode	What routes through it	Use it for
Per-agent	Only agents that switch on Route through gateway in their tool settings. Everything else talks to providers directly.	Trying the gateway on one workload before committing to it.
Route all	Every LLM call on the account: chat, swarms, BI answers, embeds, skill generation, notebooks, model listings and embeddings.	The one-gateway-one-bill pattern — central rate limits, central spend, one audit trail.

Enabling either mode validates against the gateway first, so a wrong key fails at configuration time rather than on someone's next question. An auth failure blocks activation; a gateway that does not expose /models is tolerated, since not all of them do.

Route all is routing, not an egress boundary

If the gateway integration cannot be read at call time — a database blip, a config that failed to resolve — the call goes direct to the provider rather than failing. That is deliberate: a transient lookup problem taking down every model call on the instance would be worse. But it means route all is not something to rely on as the control that guarantees no traffic ever reaches a provider directly. If you need that guarantee, enforce it at the network, and use this for billing and observability.

Shared credentials (teams)

A superadmin can grant one user's LLM credential to other users or groups under Admin → IAM (resource types “LLM key” and “LLM credential”) — the enterprise pattern of one provisioned Bedrock or OpenAI credential for a whole team.

Which key actually pays

Worth knowing precisely, because it decides which account gets the bill. The first match wins:

1
The caller's own connection
If you have connected that provider yourself, your key is used — always. A grant never displaces your own credential.
2
A credential granted to you
Resolved server-side at call time and shown as “Shared with you” on the Integrations page. You can use it; you can never read it.
3
The operator's environment default
The shared key the instance was configured with, if there is one. This is what makes a brand-new account work before anything is connected.

Sharing a key does not share anything else

A grantee's calls still run under their own model rules, their own budget caps, and their own traces. What changes is whose provider account the tokens are billed to — so the spend lands on the credential owner while the governance stays with the caller. Cap the credential itself if you need to bound what a shared key can cost.

Notification channels

The Notifications tab connects Slack, Microsoft Teams, Discord, or any custom webhook. Connected channels receive system alerts (failing credential health checks, scheduled-refresh errors, BI data alerts) alongside the in-app notification bell, and power the send_notification agent tool (enable it per agent under Agent Builder → Tools → Automation). Saving posts a visible test message first; webhook URLs are capability URLs, so they are encrypted at rest and never shown again.

n8n workflows

The n8n Workflows tab connects an n8n instance by webhook URL and token, letting agents trigger your automations as a tool. The same pattern extends to the other automation platforms configurable per-agent in the Agent Builder (Activepieces, Node-RED, Windmill, Temporal, Airflow, Zapier, Make, or a plain webhook).

MCP servers

/mcp attaches Model Context Protocol servers to your workspace. On connect, the platform probes the server and discovers the tools it exposes; agents can then be granted access to specific servers from the Agent Builder's tool section.

Treat every key you connect as spend authorization: pair bring-your-own-key providers with budget caps, and per-agent limits in the guardrails section.

What can be connected

Category	Connects	Documented in
Model providers	14 providers — OpenAI, Anthropic, Gemini, Vertex, Bedrock, Azure OpenAI, OCI, Grok, Qwen, Groq, NVIDIA, OpenRouter, Ollama, vLLM	Models & providers
Data sources	22 database/warehouse connectors queried in place, 5 apps synced into datasets, plus object stores and lakehouse catalogs	Data Catalog & SQL
Web search	Firecrawl (built in), Brave, Tavily, SerpAPI; ScrapingBee for page fetching	Agent Builder → Tools
Automation	n8n workflows, triggered by an agent tool	Agent Builder → Tools
Notifications	Slack, Microsoft Teams, Discord, custom webhooks — system alerts + the send_notification agent tool	Agent Builder → Tools
MCP servers	Any Streamable HTTP MCP endpoint	MCP servers

SaaS tools (Google Drive, Jira, GitHub, CRMs…) connect through MCP servers or n8n workflows — that is the deliberate strategy, not a gap in the catalog. Native per-provider OAuth connectors would require every operator to register their own OAuth apps with each vendor, so they are not shipped in the self-hosted build.

Credential handling

Every secret is encrypted at rest and never returned to the browser after saving.
Prefer a Secrets reference over pasting a value, so rotation is one edit rather than a hunt through every connection.
Test connection stores its result and error on the connection, so you can see when something started failing rather than discovering it through a broken dashboard.
Scheduled health checks re-run the same live tests every 6 hours (set INTEGRATION_HEALTH_HOURS to change, 0 to disable). A key revoked upstream shows as a “failing health checks” badge, sends an in-app notification, and lands in the audit trail — before an agent run trips over it. Health results never auto-disable a connection.
Connecting, changing, or deleting any credential is recorded in the audit trail — names, URLs and whether a secret was rotated; never the secret itself.
Disconnect asks for confirmation and tells you what depends on the connection first.

Outbound requests are guarded

Connector endpoints resolving to private, loopback or link-local addresses are refused unless the deployment explicitly allows them. A database on a private network must be reachable from wherever the app runs — see Install & deploy.

PreviousBI Workspace Next Models & providers