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 the Ema Platform Integrations catalog (prebuilt integrations for popular apps and services) and connect and test their Tools; build your own with custom integrations that wrap any other API; register your own Model Context Protocol (MCP) servers; set up data connectors; and configure the channels an AI Employee is reachable on.

The page is organized into tabs:

All: the integrations catalog. Browse, search, and filter by category; connect an integration; or build 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.
Ticketing: the Workspace-level connections a group's ticket queue can run on. See Ticketing.
Audit Logs: every connection and configuration change, plus each Tool execution, with the actor and timestamp.

The catalog

The All tab lists every integration visible to your Workspace. 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 Workspace 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.

Setting up an integration

Building your own. You can create a new integration directly from the integrations list page using the Create integration dialog. The dialog walks you through four steps:

About — name, describe, and categorize the integration.
Authentication — declare the auth scheme and the credentials it needs.
Connections — create a live, authenticated connection to run against.
Tools — build the individual capabilities the integration exposes.

Using one that's already built. For an Ema Platform Integration (or a custom integration you've already built), the About and Tools come predefined. You just connect (authenticate once) and start using its Tools.

Roles. 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 an integration needs to authenticate from the live connections built from it. That separation is what lets one integration safely serve many users and Workspaces. Three ideas work together:

1. Auth scheme: how an integration authenticates. When you build an integration, you define its auth scheme once, at setup: the auth type (API key, Basic, OAuth2, and so on) and the fields it requires (a token, a client ID and secret, a base URL, and so on). This is a definition — you're describing what's needed to authenticate, not connecting yet.

2. Connection template, then connection: the two steps to go live.

A connection template (CT) captures the reusable setup: shared values like a base_url, a client_id and client_secret, and which Tools are enabled. An admin typically sets this up once.
A connection is created when someone connects under that template: a live, authenticated session that Tools actually run against. For OAuth2, connecting opens the provider's consent screen in a popup; approving it activates the connection.

You can create more than one template for the same integration, each pointing at a different instance or account of the system (for example a production and a sandbox site, or two separate accounts).

3. Connection type: Shared or User. A template is one of two types:

Shared: a single connection under the template that everyone uses; all users of the AI Employee act through the same account.
User: each user connects their own account under the template. When a workflow runs, it uses the caller's own connection: the same template settings, but each person's own access.

Default: one user-level auth per Workspace. By default, a Workspace has a single user-level authentication set up per integration — everyone in the Workspace connects their own account under that one User template.

Example: Gmail. Say you set up a Gmail integration whose template defines OAuth2 and the Gmail API base URL. Make it Shared, and one Gmail account is connected once and every user of the AI Employee sends mail through it. Make it User, and each person connects their own Gmail the first time they use the AI Employee. The workflow then reads and sends as them: same template, separate mailboxes.

Viewing and editing auth configuration

The configured auth card on an integration's detail page rests as a summary view showing the current auth scheme and the state of each credential field. To change any auth settings, select Edit to open a drawer where you can update the scheme, field values, and connection parameters. Changes in the drawer take effect when you save.

When to use Shared vs User

Choose the connection type by whose account the work should run as:

Shared: everyone acts through one account. Say you're building a support AI Employee that must send every email from [email protected]. Set up a Shared template with a single connection under it. Whoever triggers the AI Employee (any support-team member, or an external user) sends from that same mailbox.
User: everyone acts as themselves. Say you're building an assistant that fetches email from each person's own inbox. An admin sets up a User template and points the AI Employee at it; every user then connects their own account under that template. When user A runs the AI Employee, its Gmail Tools reach only A's own mailbox; when user B runs it, only B's.

Credentials are encrypted at rest and are never returned in API responses. The UI shows only whether a credential is set. Read-only and read-write credentials are held separately, so a read-only token can never be used for a write.

For OAuth2, Ema gives you a single callback URL to register once in the provider's console. Ema refreshes an access token lazily (at the next Tool call, when the token is at or near expiry) rather than maintaining it in the background. If a refresh fails outright (the provider rejects it), the connection moves to an error state and prompts an admin to reconnect.

HTTP connectors automatically retry once after a 401 response by refreshing the OAuth token and re-executing the request. If the retry also returns 401, the connection moves to an error state.

MCP servers

The MCP servers tab lets you connect external Model Context Protocol servers so their tools become available to your AI Employees. See the dedicated MCP Servers page for the full guide. 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 Workspace; 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.

Running a Tool

A Tool can be run in three places: from its Test panel (Integrations → the integration → the Tool → Test), by an agent inside a workflow, or from Ema Autopilot. However it runs, two guarantees apply to every Tool call:

PII redaction. Before a Tool's outbound data leaves Ema, it passes through PII redaction: only the entity types your Workspace's per-integration allow-list permits are sent in the clear; locked types (card CVV, credentials, special-category personal data) always stay tokenized. If redaction can't be applied, the call fails rather than send unprotected data.
Audit trail. Every Tool call is recorded. Review it in the Audit Logs tab and on each integration's Activity view.

What's next

Custom Integrations — build your own integration and its Tools.
MCP Servers — add your own MCP server and use the tools it exposes.
Data Connectors — sync external documents into Knowledge bases.