Integrations Hub
The Integrations page is the single place where you give your AI Employees the ability to act in external systems. From here you browse a catalog of ready-made integrations, install and authenticate them, register your own Model Context Protocol (MCP) servers, set up data connectors, and configure the channels an AI Employee can be reached on. Every capability you enable here becomes a Tool that an agent can call inside a workflow.
Open it from the AI Employee builder. The page is organized into tabs:
- All — the integrations catalog. Browse, search, and filter by category; install an integration; or create your own.
- MCP servers — register external MCP servers and manage the tools they expose.
- Data sources — set up connectors that sync documents into Knowledge bases. See Data Connectors.
- Channels — configure where an AI Employee is reachable: Microsoft Teams and the embeddable web chat widget. See Embeddable Chat SDK.
- Audit log — every install, connection, and configuration change, with the actor and timestamp.
The catalog
The All tab lists every integration visible to your tenant. Each tile shows the integration's name, logo, category, and a status badge — Connected when it is fully set up and ready to use, or Not connected when it still has outstanding setup. The catalog is grouped into sections:
- Made by you — custom integrations your tenant authored. See The Tool Editor for how these are built.
- Category sections — prebuilt integrations grouped by domain: accounting, analytics, ATS, communication, CRM, ecommerce, file storage, marketing, productivity, and ticketing.
Use the search box to filter by name, the category pills to jump to a domain, and the status filter to show only connected or only not-connected tiles.
Installing an integration
Selecting a prebuilt tile for the first time installs it — it creates a tenant installation record — and opens the guided setup. From there you complete the integration's setup steps:
- About — name, description, and category.
- Authentication — the auth scheme and credentials the integration needs (see below).
- Connections — one or more live connections built from those credentials.
- Tools — the individual capabilities the integration exposes.
A custom integration or an already-connected integration takes you straight to this guided setup shell when you select it.
Roles. Installing, connecting, and editing integrations requires a builder or admin role. Members with view-only access can see connected integrations but cannot change them.
Authentication and connections
Ema separates what credentials an integration needs from the live connections built from them. This separation is what lets one integration serve many users and tenants safely.
- Auth scheme — how the integration authenticates. Supported schemes are
api_key,basic,oauth2(authorization-code flow with user consent),oauth2_client_credentials(machine-to-machine OAuth2, no interactive sign-in), andnone. Custom integrations declare a structured set of auth fields under a chosen scheme; the scheme is fixed once configured. - Connection template (CT) — a reusable connection definition for an integration. A CT can be tenant-level (one shared connection the whole tenant uses) or user-level (each user connects their own account). Tools run against the active CT for the caller.
- Connection — a live, authenticated connection created under a CT. For OAuth2, connecting opens the provider's consent screen in a popup; the callback marks the connection active.
Credentials are encrypted at rest and are never returned in API responses — the UI shows only a boolean indicator that credentials are present. Read-only and read-write credentials are stored in separate columns so a read-only token can never be used for a write call.
For OAuth2 integrations, Ema derives a single server-side callback URL that you register once in the provider's developer console. When an access token nears expiry, Ema refreshes it proactively before the Tool call; a terminal refresh failure flips the connection to an error state and prompts an admin to reconnect rather than silently retrying.
Composio-backed integrations
Some catalog integrations are backed by Composio. For these, Ema stores your admin-supplied auth config (client ID, secret, scopes) locally encrypted and mirrors it to Composio; access and refresh tokens are held and rotated by Composio, never stored in Ema. Connecting initiates a Composio connected account and, when the scheme needs it, returns a redirect URL for the OAuth popup.
MCP servers
The MCP servers tab lets you connect external Model Context Protocol servers so their tools become available to your AI Employees. Register a server with:
| Field | Notes |
|---|---|
| Name | Display name for the server. |
| Server URL | The MCP server endpoint. |
| Auth type | none, bearer_token, api_key, or basic_auth. |
| Auth mode | central — one shared credential for the tenant; or per_user — each user supplies their own. |
| Credentials | JSON credential blob (central mode only). Encrypted at rest. |
Registration triggers automatic tool discovery: Ema connects to the server, caches the tools it advertises, and sets the server to Pending review. No tools are usable until an admin explicitly activates the server.
The server lifecycle is deliberate:
- Pending review → an admin selects Activate to move it to Active.
- Active → tools are callable. An admin can Disable at any time.
- Disabled / Discovery failed → an admin can Enable, which re-queues discovery and returns the server to Pending review.
From the actions menu you can View tools (the cached tool list), Refresh tools (re-discover from the server), and Delete the server — deletion is blocked while an active agent still binds to it.
Editing a server's URL or credentials automatically re-triggers discovery and returns it to Pending review, so a changed endpoint never silently serves stale tools.
Ema can also expose its own AI Employee tools to MCP-aware clients through a separate MCP gateway product. That is the reverse direction — Ema as an MCP server — and is documented with the MCP product, not here.
How Tool calls are executed
You never choose an execution strategy when wiring a Tool into a workflow — the agent calls the integrations service and it routes to the correct executor based on the Tool's definition:
| Executor | What it does | Example |
|---|---|---|
http | Resolves templates and makes an outbound HTTP request with auth injected | Slack "Send message," most REST integrations |
mcp | Invokes a tool on a registered MCP server | Any tool from an active MCP server |
composio | Proxies the call to Composio, which handles auth and execution | Composio-backed catalog integrations |
script | Runs a built-in Go-native handler that calls a vendor API directly | Web Search, Market Data, SysAid, Wipro SuccessFactors |
ts_script | Runs a custom TypeScript function in a sandboxed runtime | TypeScript Tools you author in the Tool editor |
A sixth catalog kind, connector, is metadata only — it describes a data source's sync capability but is never executed as a Tool. Connector syncs run in the ingestion service as background jobs; see Data Connectors.
Every outbound Tool-call payload — an HTTP body, MCP tool arguments, or a script's input — is passed through Ema's PII rendering layer before it leaves the platform. Only the entity types your tenant's per-integration allow-list permits are rendered to their original values; locked types (such as card CVV, credentials, and special-category personal data) always stay tokenized. If PII rendering fails, the Tool call fails — Ema never falls back to sending un-rendered text.
Every execution — regardless of executor — is recorded in an audit trail you can review in the Audit log tab and on each integration's Activity view.
What's next
- The Tool Editor — author and publish a Tool inside an integration.
- Data Connectors — sync external documents into Knowledge bases.
- Embeddable Chat SDK — put an AI Employee on your own website.