Integrate & ship

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.

Web search & browsing#

The Web Search tab holds one workspace-wide Firecrawl key, which powers the web_search and web_browse tools for every agent that has them enabled.

It works with no key at all

web_browse falls back to a built-in fetcher: it requests the page, strips navigation, headers, footers and cookie banners, and converts what is left to markdown — tables included. It does not run JavaScript, so a server-rendered page (documentation, a blog post, a licence, a GitHub README) reads cleanly while a client-rendered app returns its empty shell. When that happens the result is flagged as thin and says so, rather than handing the model nothing and calling it an answer. Adding a URL as a knowledge-base source uses the same fetcher.

web_search falls back to DuckDuckGo's Instant Answer API. That is a category difference rather than a quality one: it returns encyclopedia-style entries for recognised entities and has no ranked web results at all, so ordinary queries come back empty however they are phrased. A key is what turns it into real search.

The same setting can come from three places, in this order:

Source	Scope	Wins over
A per-agent key in the agent editor	That one agent	Everything below
`FIRECRAWL_API_KEY`	The deployment	The workspace default
This tab	Workspace default	Nothing — it is the fallback

Keys are stored encrypted and never shown again; leaving the field blank keeps the saved key rather than clearing it. Saving validates the key first, so a wrong paste fails here instead of silently degrading every agent's search to DuckDuckGo.

Agents can also use Brave, SerpAPI, Tavily or ScrapingBee instead — those are chosen per-agent on the Tools tab, not here. See the tool reference.

Ask an AI Analyst from Slack#

The Slack tab authorises Slack workspaces to run one of your AI Analysts with a slash command. Someone types /ask in a channel, the analyst answers there, and the message links back here.

Why it works this way

The answer posted to Slack is a summary. The rows, the generated SQL and the lineage stay in the app. A channel is a wide audience with no per-viewer permissions, so publishing internal table and column names into it is not a thing you can take back — the link is there for anyone who needs the detail and is allowed to see it.

This tab sits beside Notifications because both are Slack-shaped, but they point in opposite directions: notifications post out to a webhook you supply, while this accepts calls in. That difference is what makes the signing secret mandatory.

1
Copy the request URL
Shown at the top of the tab — /api/slack/command on your deployment. Slack has to reach it over the public internet.
2
Create the slash command in Slack
In your Slack app: Slash Commands → Create New Command. Name it /ask and paste the request URL.
3
Copy the signing secret
Basic Information → Signing Secret. Paste it here when you add the workspace. It is written once and never read back.
4
Add the workspace here
Workspace ID (like T01AB2CD3EF), an optional name, and the analyst that answers. A bot token is not needed for slash commands — replies go back through Slack's own response URL.

Configured and working are different things

The tab shows those as two separate states on purpose. Configured only means a form was filled in. Receiving commands is backed by a timestamp only Slack can set, so it is the one that proves the round trip works. If a row stays configured but never receives anything, the usual causes are that the deployment is on localhost and unreachable from Slack, a typo in the request URL, or a Slack app that was never reinstalled after the command was added.

The endpoint is public because Slack has to reach it, so the signing secret is the only thing separating a real slash command from anyone who learned the URL. Deleting a workspace stops /ask working there immediately.

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.

Answering in Microsoft Teams#

The same idea as Slack, through a Bot Framework registration. Under Integrations → Teams: paste the bot's Microsoft App id and a client secret, choose the agent or analyst that answers, and put https://<your host>/api/teams/messages in the bot's Messaging endpoint in the Azure portal. The turn runs as the bot's owner, with the same model rules, budgets, traces and audit rows as everywhere else.

The secret is not optional. A Slack slash command arrives with a reply URL that needs no credential; the Bot Framework never sends one, so every answer is posted with a token minted from the client secret. A bot without one receives questions and cannot answer them.
A single-tenant bot should name its tenant. Left empty the registration answers any organisation Microsoft routes to it; with a tenant id set, another tenant's activity is refused.
It never answers itself. Teams delivers a bot its own posts, and a bot that answers itself never stops.

How an inbound request proves itself

Slack signs with a shared secret, so verifying is an HMAC. Microsoft signs with a rotating RSA key it publishes, so verification checks the signature against that published key — never one the token brought with it — plus the issuer, the audience (this bot's App id) and the service URL the token authorises. That last one is what stops an attacker making the bot post its answer to a host they control. The algorithm is pinned to RS256 rather than read from the token, and every check fails closed.

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, 17 apps synced into datasets, plus object stores and external table 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.

PreviousKnowledge Base Next Models & providers