Connections

A connection is a saved, authenticated link to an external system. Integration triggers and actions reference a connection instead of carrying their own credentials, so you authenticate once and reuse it across automations.

Manage connections on the Connections page. It lists your existing connections with their status, and lets you create a new one by choosing a connection type. A connection that has lost its authentication is flagged so you can reconnect it. The same page manages MCP servers—the tool sources AI agents draw from.

For the fields of each connection type, see the Reference.

Connecting a system

How you authenticate depends on the system:

• OAuth connections show a Connect button. Clicking it sends you to the provider to sign in and authorize access, then returns you with the connection active. A Disconnect action tears the authorization down.
• Credential connections store a token or key you paste in directly.

Once active, a connection shows a confirmation with the connected identity.

Connection types

Connection	Authentication
Brightspot	OAuth 2.0 to a Brightspot CMS. Enter the instance's base URL and click Connect—the rest is configured automatically. A connected CMS is what the Content trigger and Content action act on.
Jira	An API Token (your Atlassian account email plus a token) or OAuth 2.0 (3LO). OAuth is required for triggers that register their Jira webhooks automatically.
GitHub	A Personal Access Token (tied to a user) or an App Installation (tied to an organization, surviving personnel changes).
Slack	OAuth to a Slack app. Click Connect to install the app into your workspace. A signing secret lets Slack's interactive messages—used for approvals—call back securely.
Custom OAuth	Any OAuth 2.0 service. Paste a discovery URL to configure it automatically, or enter the authorize and token endpoints by hand.

note

Some connections need setup by an administrator before you can connect:

• Brightspot (the CMS you are connecting to must have the Esca server module installed). Without it, Connect has nothing to talk to. If connecting fails right away, ask your administrator whether the module is installed on that CMS.

  The module's version matters too. A CMS running an older version connects successfully but cannot run every node, because some nodes need capabilities a later version added. Once connected, the Automation Plugin row on the connection shows the version that CMS is running, and the version to upgrade to when something you can build needs a newer one. Nodes affected by the gap say so on the canvas, and a run that hits one names the version it needs.

• Jira, GitHub, Slack, Custom OAuth (an administrator may need to register an application with the provider first and give you its credentials, for example an OAuth client ID and secret). For Slack, see Setting up the Slack connection below.

MCP servers

The Connections page also manages MCP servers—the tool sources the AI Agent action and the AI Judgment condition draw from. Where a connection authenticates Esca to a system its triggers and actions call directly, an MCP server gives an AI agent a set of tools it can call as it works.

An MCP server is not a connection. It authenticates against its own endpoint, separately from any connection to the same system—a Brightspot connection, for example, does not authenticate an agent to that CMS's MCP endpoint. A server's name also identifies its tools to the agent, so give each server a short, recognizable name.

To add an MCP server:

1. On the Connections page, under MCP Servers, select a server type from the dropdown list, and click +.
2. Complete the fields for the type.
3. If the server uses OAuth, click Connect and authorize access. The server shows Connected when authorization succeeds.

MCP server types

Server	Configuration
Brightspot	The MCP endpoint of a Brightspot CMS. Enter the endpoint's URL and choose the authentication that endpoint is configured for—OAuth or API Key.
Custom	Any remote MCP server, reached by URL. For a public server, the URL alone is enough. For a server that requires OAuth, enable Requires OAuth—endpoints are discovered from the URL, and a client is registered automatically unless you supply a pre-registered Client ID and Client Secret.

For field-by-field detail, see MCP servers in the Reference.

Setting up the Slack connection

The Slack connection signs in to a Slack app that represents Esca in your workspace. An administrator creates and configures that app once; afterward the connection is reused like any other. The steps below cover building the app in Slack; the last step connects it from Esca.

Create the app at api.slack.com/apps: choose Create New App, then From scratch, give it a name, and pick the workspace it will post to. Slack opens the app's settings, where you configure the pieces Esca needs.

Note the app credentials

Open Basic Information and find the App Credentials section. The Client ID, Client Secret, and Signing Secret shown here identify the app and let Slack verify Esca's requests. Your administrator enters these into Esca's Slack configuration. Treat the secrets like passwords—don't share them.

Set the display information

Still on Basic Information, fill in Display Information: the app's name, icon, and description. This is what people see when the app posts in Slack, so choose a recognizable name and icon.

Add the OAuth scopes and redirect URL

Open OAuth & Permissions from the left sidebar.

Under Redirect URLs, add the redirect URL from Esca's Slack configuration and save. Under Bot Token Scopes, add the scopes:

• chat:write (required)—send a message to a user.
• chat:write.public (required)—send a message to a public channel the app hasn't joined.
• channels:read (recommended)—auto-populate the channel picker when configuring a Slack node.
• users:read (recommended)—auto-populate the user picker when configuring a Slack node.

chat:write and chat:write.public are the minimum needed to send messages. The other two are optional but recommended: without them a Slack node still works, but you type channel and user IDs by hand instead of choosing from a populated picker.

Enable interactivity for approvals

Slack approvals—messages with Approve and Reject buttons that drive a human-in-the-loop step—need a callback URL. Open Interactivity & Shortcuts, turn Interactivity on, and set the Request URL to the interactivity URL from Esca's Slack configuration. Slack signs each callback with the signing secret from the first step, which is how Esca confirms the request is genuine.

With the app configured, open the Slack connection on the Connections page and click Connect. That runs the OAuth flow, installs the app into your workspace, and issues the bot token Esca posts with. If you change the app's scopes later, reconnect to reinstall it. See Connecting a system for what to expect, and the Slack connection reference for its field-by-field configuration.