# Account Linking
Source: https://docs.mistle.dev/guides/account-linking

Attribute provider activity and agent work to the right Mistle user

## Overview

Account linking lets users connect their Mistle account to their identity in a supported integration provider, such as Slack or GitHub.

Organizations can enable supported integrations as account-linking providers. Once linked, Mistle can map provider activity back to the correct Mistle user, so actions, workflow runs, and agent work are attributed to the right person.

For GitHub-backed Sandbox profiles, account linking also gives Mistle a user-specific Git actor when the linked user starts or resumes a sandbox. If the acting user has not linked GitHub for that connection, Mistle still configures Git commits with the Git connection's own identity, such as the GitHub App bot account or API-key owner.

Git commit signing is configured separately on Sandbox profiles. Account linking can supply the user identity and signing material required for signing, but setting `git user.name` and `git user.email` does not enable signing by itself.

## Example Flow

In this example, a user asks an agent to do work from Slack. The agent completes the work and opens a pull request in GitHub.

Account linking lets Mistle connect:

* the Slack user who requested the work
* the Mistle user account
* the GitHub identity involved in the resulting pull request

Without account linking, Mistle may know that a Slack user triggered work and that a GitHub connection opened a pull request, but it cannot reliably prove those identities belong to the same person.

## What Account Linking Enables

* accurate requester attribution for work triggered from provider events
* correct user context for agent workflows
* clearer audit trails across Slack, GitHub, and Mistle
* safer trigger behavior when provider activity needs to resolve to a known user

## Set Up Account Linking

Account linking has two parts:

* an organization owner or admin enables the provider for the organization
* each user links their own provider account from their profile settings

### 1. Create An Eligible Integration Connection

First, create an active integration connection for the provider you want to use for identity linking.

Current identity-linking providers require these connection methods:

| Provider | Required connection method |
| -------- | -------------------------- |
| GitHub   | GitHub App installation    |
| Slack    | Slack app                  |

The connection also needs the linked-user authorization fields for that provider:

* GitHub: `Client ID (Linked User Auth)` on the GitHub App installation connection.
* Slack: `Client ID (Linked User Auth)` and `Client secret (Linked User Auth)` on the Slack app connection.

These values come from the provider app that users authorize during account linking. For GitHub, use the GitHub App's client ID. For Slack, use the Slack app's client ID and client secret.

If the connection does not appear as an option in Identity Linking settings, check that it is active and uses the required connection method.

### 2. Enable The Provider For The Organization

Organization owners and admins can enable identity linking from the dashboard:

1. Open **Settings**.
2. Go to **Organization > Identity Linking**.
3. Find the provider row, such as GitHub or Slack.
4. Select the eligible integration connection.
5. Turn on **Enable \[provider] identity linking**.

<Frame>
  <img alt="Organization identity linking settings with provider rows, connection labels, users linked status, and enable toggles" />
</Frame>

Once enabled, users in the organization can link their own account for that provider.

### 3. Ask Users To Link Their Accounts

Each user links their own provider account from profile settings:

1. Open **Settings**.
2. Go to **Account > Profile**.
3. Find **Linked Accounts**.
4. Select **Link account** for the provider.
5. Complete the provider authorization flow.

<Frame>
  <img alt="Profile linked accounts settings showing GitHub and Slack linked-account cards" />
</Frame>

After linking, the card shows the linked provider account. If authorization later expires or needs to be refreshed, the same card shows **Relink**.

GitHub linked accounts can also show Git-specific settings such as commit email and commit signing key configuration.

## View Linked Identities

Organization owners and admins can see linked identities from the same organization settings page:

1. Open **Settings**.
2. Go to **Organization > Identity Linking**.
3. Use the **Users Linked** column for the provider.
4. Select the view action for that provider.

The link status sheet shows each organization member's Mistle name, email, and link status.

## Next Steps

* Read [Integrations](/guides/integrations) for the provider connection model.
* Read [GitHub](/guides/github-integration-setup) or [Slack](/guides/slack-integration-setup) for provider-specific identity-linking setup.
* Read [Triggers](/guides/triggers) to see how linked identities are used when events trigger agent work.


# AgentMail
Source: https://docs.mistle.dev/guides/agentmail-integration-setup

Connect AgentMail to Mistle

## Overview

Connect to AgentMail through AgentMail's hosted remote MCP server and OAuth flow.

The AgentMail integration exposes inbox, thread, message, draft, and attachment tools to agent runtimes through `https://mcp.agentmail.to/mcp`.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **AgentMail**, then select **AgentMail OAuth**.

The browser redirects to AgentMail, the user signs in, chooses an organization when prompted, and the returned OAuth credentials are stored for the connection.

There are no user-entered secret fields for this target.

## Official References

* [AgentMail MCP documentation](https://www.agentmail.to/docs/integrations/mcp)
* [AgentMail remote MCP server](https://github.com/agentmail-to/agentmail-manufact-mcp)

This integration uses the hosted MCP server at `https://mcp.agentmail.to/mcp`.


# Anthropic
Source: https://docs.mistle.dev/guides/anthropic-integration-setup

Connect Anthropic model access to Mistle

## Overview

Anthropic provides model access for sandbox profiles that use the OpenCode agent runtime.

Use this connection when an OpenCode profile should be able to call Anthropic models through an API key managed by Mistle.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Anthropic**, then select **API key**.

Enter:

| Field   | Value             |
| ------- | ----------------- |
| API key | Anthropic API key |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use Anthropic.
2. In **Runtime**, set **Agent** to **OpenCode**.
3. Add Anthropic as a model provider connection.
4. Save and publish the profile version.

Anthropic connections are only available to OpenCode profiles. Codex profiles use OpenAI-compatible model-provider connections instead.


# Autumn
Source: https://docs.mistle.dev/guides/autumn-integration-setup

Connect Autumn to Mistle

## Overview

Connect to Autumn through Autumn's hosted MCP server with an Autumn secret key.

The Autumn integration exposes billing, customer, plan, balance, and request-log workflows to agent runtimes through Autumn's official hosted MCP endpoint.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Autumn**, then select **Secret key**.

Enter:

| Field             | Value                                                                            |
| ----------------- | -------------------------------------------------------------------------------- |
| Autumn secret key | Autumn secret key with access to the organization billing data agents should use |

Mistle stores the secret key on the connection and injects it into requests to Autumn MCP through managed egress.

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use Autumn.
2. Add Autumn to the profile's integration configuration.
3. Select the Autumn MCP server.
4. Save and publish the profile version.

## Official Reference

* [Autumn MCP server documentation](https://docs.useautumn.com/documentation/mcp)

This integration uses the hosted MCP server at `https://mcp.useautumn.com/mcp`.


# AWS
Source: https://docs.mistle.dev/guides/aws-integration-setup

Connect AWS to Mistle

## Overview

Connect to AWS by using an IAM user's access key to assume the IAM role you specify.

## Configuring AWS Access

Before creating the connection, make sure:

1. You have an IAM user or IAM principal that can call `sts:AssumeRole`.
2. You have an IAM role with the permissions you want to use.
3. That role's trust policy allows that principal to assume it.
4. If you use third-party-style cross-account protection, you have the external ID value ready for the connection.

## Example: CloudWatch Read-Only Role

For CloudWatch and CloudWatch Logs, the connection needs both a source IAM user and a target IAM role:

```text theme={null}
IAM user access key
    -> calls sts:AssumeRole
IAM role
    -> grants CloudWatch and CloudWatch Logs permissions
```

Do not put an IAM user ARN in the **Role ARN** field. Use a role ARN such as:

```text theme={null}
arn:aws:iam::123456789012:role/mistle-cloudwatch-role
```

Do not use a user ARN such as:

```text theme={null}
arn:aws:iam::123456789012:user/mistle-cloudwatch-source
```

One minimal setup is:

1. Create an IAM user for the source access key, for example `mistle-cloudwatch-source`.
2. Create an access key for that user. Use its access key ID and secret access key in the Mistle connection form.
3. Create an IAM role for the sandbox permissions, for example `mistle-cloudwatch-role`.
4. Give the IAM user permission to call `sts:AssumeRole` on that role.
5. Give the IAM role read-only CloudWatch permissions.
6. Configure the role trust policy so the role trusts the IAM user.

The IAM user needs permission to assume only the target role:

```json theme={null}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123456789012:role/mistle-cloudwatch-role"
    }
  ]
}
```

Attach CloudWatch permissions to the role, not to the source user. For broad testing, AWS-managed `ReadOnlyAccess` is usually enough. For a narrower production setup, start with AWS-managed `CloudWatchReadOnlyAccess` and `CloudWatchLogsReadOnlyAccess`, then narrow further if your account policy requires it.

The role trust policy must allow the source user to assume the role:

```json theme={null}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/mistle-cloudwatch-source"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

## Connect In Mistle

Open **Integrations** in the dashboard, choose **AWS**, then select **Access key + AssumeRole**.

Enter:

| Field             | Value                                                   |
| ----------------- | ------------------------------------------------------- |
| Access key ID     | IAM user access key ID                                  |
| Secret access key | IAM user secret access key                              |
| Role ARN          | Role ARN that Mistle should assume                      |
| External ID       | Optional external ID if your trust policy requires one  |
| Duration seconds  | Optional STS session duration between `900` and `43200` |

If the connection fails with `AccessDenied` during STS `AssumeRole`, check that the source access key belongs to the intended principal, the source principal can call `sts:AssumeRole` on the role, the role trust policy allows that source principal, and the external ID matches if one is configured.

If CloudWatch or CloudWatch Logs returns `AccessDenied`, Mistle assumed the role, but the role lacks permission for the requested CloudWatch or Logs action.

## Official References

* [AWS IAM access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)
* [Create a role using custom trust policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html)
* [Granting third-party access with IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)


# BugSnag
Source: https://docs.mistle.dev/guides/bugsnag-integration-setup

Connect BugSnag to Mistle

## Overview

Connect to BugSnag through SmartBear's hosted BugSnag MCP server and BugSnag OAuth.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **BugSnag**, then select **BugSnag OAuth**.

The browser redirects to BugSnag, the user approves access, and the returned OAuth credentials are stored for the connection.

There are no user-entered secret fields, project filters, or per-tool restrictions for this target.

## Official Reference

* [SmartBear BugSnag MCP integration](https://developer.smartbear.com/smartbear-mcp/docs/bugsnag-integration)

This integration uses the hosted MCP server at `https://bugsnag.mcp.smartbear.com/mcp`.


# Cloudflare
Source: https://docs.mistle.dev/guides/cloudflare-integration-setup

Connect Cloudflare to Mistle

## Overview

Connect to Cloudflare with a Cloudflare API token.

This integration exposes Cloudflare API MCP Code Mode access to agent runtimes through the Cloudflare MCP server catalog selected on the sandbox profile.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Cloudflare**, then select **API token**.

Enter:

| Field                | Value                                                                   |
| -------------------- | ----------------------------------------------------------------------- |
| Cloudflare API token | Cloudflare API token scoped to the account operations agents should use |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use Cloudflare.
2. Add Cloudflare to the profile's integration configuration.
3. Select the Cloudflare MCP servers the profile should expose.
4. Save and publish the profile version.


# Datadog
Source: https://docs.mistle.dev/guides/datadog-integration-setup

Connect Datadog to Mistle

## Overview

Connect to Datadog by providing a Datadog API key and application key.

## Configuring Datadog Access

Before creating the connection, make sure:

1. You have a Datadog API key.
2. You have a Datadog application key with the scopes you want to use.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Datadog**, then select **API key + application key**.

Enter:

| Field           | Value                   |
| --------------- | ----------------------- |
| API key         | Datadog API key         |
| Application key | Datadog application key |

## Official References

* [Datadog API and application keys](https://docs.datadoghq.com/account_management/api-app-keys/)


# DataForSEO
Source: https://docs.mistle.dev/guides/dataforseo-integration-setup

Connect DataForSEO to Mistle

## Overview

Connect to DataForSEO through DataForSEO's hosted MCP server and DataForSEO OAuth.

The DataForSEO MCP server lets agents access SEO and marketing data from the official DataForSEO APIs, including SERP, keyword, backlinks, on-page, domain analytics, app, merchant, and business data capabilities.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **DataForSEO**, then select **DataForSEO OAuth**.

The browser redirects to DataForSEO, the user approves access, and the returned OAuth credentials are stored for the connection.

## Access Scope

This integration requests DataForSEO's `api` OAuth scope for the hosted MCP server.

Review agent tool calls before approving DataForSEO requests that may create provider-side API costs.

## Official Reference

* [DataForSEO Model Context Protocol](https://dataforseo.com/model-context-protocol)
* [Connecting the remote DataForSEO MCP server using OAuth](https://dataforseo.com/help-center/connecting-the-remote-dataforseo-mcp-server-using-oauth)
* [Setting Up the Official DataForSEO MCP Server](https://dataforseo.com/help-center/setting-up-the-official-dataforseo-mcp-server-simple-guide)

This integration uses the hosted MCP server at `https://mcp.dataforseo.com/mcp`.


# DeepSeek
Source: https://docs.mistle.dev/guides/deepseek-integration-setup

Connect DeepSeek model access to Mistle

## Overview

DeepSeek provides model access for sandbox profiles that use OpenCode-compatible agent runtimes.

Use this connection when a profile should call DeepSeek models through an API key managed by Mistle.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **DeepSeek**, then select **API key**.

Enter:

| Field   | Value            |
| ------- | ---------------- |
| API key | DeepSeek API key |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use DeepSeek.
2. Add DeepSeek as a model provider connection.
3. Save and publish the profile version.


# E2B
Source: https://docs.mistle.dev/guides/e2b-integration-setup

Connect E2B sandbox runtime access to Mistle

## Overview

E2B provides a sandbox runtime for running Mistle sandboxes with an organization-owned E2B API key.

Use this connection when a sandbox profile should use workspace-owned E2B credentials instead of deployment-level runtime credentials.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **E2B**, then select **API key**.

Enter:

| Field   | Value       |
| ------- | ----------- |
| API key | E2B API key |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should run on E2B.
2. Choose **E2B** as the sandbox runtime.
3. Select the E2B credentials connection.
4. Save and publish the profile version.

For self-hosted deployments, the E2B runtime must also be enabled in deployment configuration before profiles can use it.


# Expo
Source: https://docs.mistle.dev/guides/expo-integration-setup

Connect Expo to Mistle

## Overview

Connect to Expo through the Expo hosted MCP OAuth redirect flow.

The Expo integration exposes server-side Expo MCP capabilities to agent runtimes, including Expo documentation, compatible package installation guidance, EAS builds, EAS workflows, and TestFlight data.

Local simulator and React Native DevTools capabilities are not enabled by this integration.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Expo**, then select **Expo MCP OAuth**.

The browser redirects to Expo, the user approves access, and the returned OAuth credentials are stored for the connection.

There are no user-entered secret fields for this target.

## Official References

* [Using Model Context Protocol (MCP) with Expo](https://docs.expo.dev/mcp/)
* [Expo logos](https://github.com/expo/logos)

The exact redirect flow in this guide is based on the current Expo MCP OAuth discovery metadata.


# Fireworks AI
Source: https://docs.mistle.dev/guides/fireworks-integration-setup

Connect Fireworks AI model access to Mistle

## Overview

Fireworks AI provides model access for sandbox profiles that use OpenCode-compatible agent runtimes.

Use this connection when a profile should call Fireworks AI models through an API key managed by Mistle.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Fireworks AI**, then select **API key**.

Enter:

| Field   | Value             |
| ------- | ----------------- |
| API key | Fireworks API key |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use Fireworks AI.
2. Add Fireworks AI as a model provider connection.
3. Save and publish the profile version.


# Google Cloud
Source: https://docs.mistle.dev/guides/gcp-integration-setup

Connect Google Cloud MCP servers to Mistle

## Overview

Connect to Google Cloud by authorizing Mistle with a Google OAuth client that you create in Google Cloud.

Mistle uses the OAuth authorization code flow to obtain Google access tokens, then uses those tokens to call Google-hosted MCP servers selected in a sandbox profile. The connected Google user remains subject to Google Cloud IAM. OAuth lets Mistle request a token; IAM decides what that token can do in each Google Cloud project and resource.

## OAuth And IAM

Google Cloud access has two independent parts:

1. **OAuth client and scopes** - identify the application and allow Mistle to obtain Google tokens. Mistle currently requests the `https://www.googleapis.com/auth/cloud-platform` scope so selected Google Cloud MCP servers can use Google Cloud APIs.
2. **IAM grants** - authorize the Google principal that completes OAuth. Grant IAM roles to that user, or to a Google group that contains that user, on the Google Cloud projects and resources the agent should access.

The Google OAuth client can live in one Google Cloud project, while IAM access can be granted in other resource projects. The user who clicks **Connect Google Cloud** must have the required IAM roles wherever the selected MCP tools will operate.

## Create A Google OAuth Client

Create a Web application OAuth client in Google Auth Platform.

1. In Mistle, open **Integrations** and choose **Google Cloud**. Mistle uses Google OAuth for this connection.
2. Copy the **callback URL** shown by Mistle.
3. In Google Cloud, open **Google Auth Platform > Clients**.
4. Create an OAuth client with **Application type** set to **Web application**.
5. Add the Mistle callback URL to **Authorized redirect URIs**.
6. Create the client and copy its **Client ID** and **Client secret**.
7. Return to Mistle, enter the client ID and client secret, and click **Connect Google Cloud**.
8. Complete the Google consent flow with the Google account that should back the connection.

If your Google Auth Platform app is in testing mode, add the authorizing Google account as a test user before connecting.

## Configure IAM

Grant `roles/mcp.toolUser` to every Google principal that will call Google-hosted MCP tools through Mistle. Then add the product-specific IAM roles for the MCP servers selected in the sandbox profile.

```bash theme={null}
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:USER_EMAIL" \
  --role="roles/mcp.toolUser"
```

Replace `PROJECT_ID` with the Google Cloud project and `USER_EMAIL` with the Google account that authorizes the Mistle connection. To grant access through a Google group, use `--member="group:GROUP_EMAIL"` for a group that contains the authorizing user.

Run the same command once for each additional role you grant:

```bash theme={null}
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:USER_EMAIL" \
  --role="ROLE"
```

If the required APIs are not already enabled, an administrator may also need `roles/serviceusage.serviceUsageAdmin` to enable them:

```bash theme={null}
gcloud services enable \
  cloudresourcemanager.googleapis.com \
  container.googleapis.com \
  logging.googleapis.com \
  run.googleapis.com \
  storage.googleapis.com
```

### MCP IAM Reference

| MCP server               | Read-only IAM to start with                           | When to grant more                                                                                                                                                                                                                                        |
| ------------------------ | ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| All Google Cloud MCPs    | `roles/mcp.toolUser` on the project                   | Required for MCP tool calls. This does not replace product-specific service permissions.                                                                                                                                                                  |
| Cloud Resource Manager   | `roles/browser` on the project, folder, or org        | `roles/mcp.toolUser` already includes basic project get/list permissions. Use broader Resource Manager roles only when agents need folder, organization, IAM policy, or project-management actions.                                                       |
| Cloud Storage            | `roles/storage.objectViewer` on the project or bucket | Use `roles/storage.objectUser`, `roles/storage.objectAdmin`, or `roles/storage.admin` for write/admin work.                                                                                                                                               |
| Cloud Logging            | `roles/logging.viewer` on the project or log view     | Use `roles/logging.privateLogViewer` for Data Access audit logs, or `roles/logging.admin` for config work.                                                                                                                                                |
| Cloud Run                | `roles/run.viewer` on the project, service, or job    | Deploy-capable access needs Cloud Run permissions plus deployment prerequisites such as Service Account User on the runtime identity and Artifact Registry access to the image source. Follow Google's Cloud Run IAM and deployment docs for write paths. |
| Google Kubernetes Engine | `roles/container.clusterViewer` on the project        | Use stronger Kubernetes Engine roles only when agents should create or modify clusters or workloads.                                                                                                                                                      |

## Connect MCP Servers To A Sandbox Profile

After the Google Cloud connection is active:

1. Open the sandbox profile that should use Google Cloud.
2. Add the Google Cloud integration connection to the profile.
3. In **Resources & Tools**, select the Google Cloud MCP servers that agents may use.
4. Publish the profile version.

Only selected MCP servers are exposed to sessions using that published profile.

## Official References

* [Google Cloud MCP servers: Manage MCP servers](https://docs.cloud.google.com/mcp/manage-mcp-servers)
* [Google Cloud MCP servers: Supported products](https://docs.cloud.google.com/mcp/supported-products)
* [Google Cloud MCP servers roles and permissions](https://docs.cloud.google.com/iam/docs/roles-permissions/mcp)
* [Google Auth Platform: Manage OAuth clients](https://support.google.com/cloud/answer/6158849)
* [OAuth 2.0 for Web Server Applications](https://developers.google.com/identity/protocols/oauth2/web-server)
* [Cloud Storage IAM roles](https://docs.cloud.google.com/storage/docs/access-control/iam-roles)
* [Cloud Logging access control](https://docs.cloud.google.com/logging/docs/access-control)
* [Cloud Run IAM roles](https://docs.cloud.google.com/run/docs/reference/iam/roles)
* [Deploying services to Cloud Run](https://docs.cloud.google.com/run/docs/deploying)
* [Use the GKE remote MCP server](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/use-gke-mcp)
* [Resource Manager roles and permissions](https://docs.cloud.google.com/iam/docs/roles-permissions/resourcemanager)
* [Browser role permissions](https://cloud.google.com/iam/docs/roles-permissions/browser)


# GitHub
Source: https://docs.mistle.dev/guides/github-integration-setup

Connect GitHub to Mistle

## Overview

GitHub can be connected in two ways:

1. **GitHub App installation**
   * **Create from manifest** (recommended): Mistle creates and configures the GitHub App via a manifest
   * **Use an existing app**: connect a GitHub App you already created in GitHub
2. **API key**
   * Use this when the connection only needs access to GitHub resources and does not need webhook events

## Option 1: Connect With A GitHub App Installation

GitHub App installation gives access through the installed GitHub App and supports webhook events from GitHub.

Choose one of these setup paths:

1. **Create from manifest** (recommended): Mistle creates and configures the GitHub App via a manifest.
2. **Use an existing app**: connect a GitHub App you already created in GitHub.

### Option 1A: Create From Manifest (Recommended)

1. Open **Integrations** in the dashboard and choose the GitHub target.
2. Select **GitHub App installation**.
3. Choose **Create from manifest**.
4. Choose whether to create the app in a personal account or organization.
5. Review and edit the manifest before creating the app.
6. Submit the manifest to GitHub.
7. Continue the installation in GitHub after the app is created.
8. Return to Mistle to complete the connection.

<Frame>
  <img alt="Mistle GitHub App setup page with Create from manifest selected and an editable GitHub App manifest" />
</Frame>

You can edit the manifest before creating the app. Mistle will use your manifest values for app settings such as the name, description, homepage URL, permissions, and subscribed events.

To keep the integration working, Mistle always overrides the webhook and callback settings when it submits the manifest. This ensures GitHub delivers webhook events to Mistle, returns the manifest flow to Mistle after app creation, supports GitHub identity linking, and redirects post-installation setup back to Mistle so the installation can be verified and the connection can be completed.

The default manifest includes the GitHub App **Email addresses** user permission with **Read-only** access. This is required for GitHub account linking because Mistle reads the authenticated GitHub user's verified email addresses during linked-account authorization.

When creating an organization-owned app, the default manifest also includes the **Members** and **Organization administration** organization permissions with **Read-only** access. Members lets Mistle sync GitHub teams from organizations with accessible repositories. Organization administration lets Mistle sync GitHub App bots from installed apps in those organizations.

If you switch the setup to a personal account, Mistle removes those organization-only permissions from the visible manifest before it is submitted.

### Option 1B: Use An Existing GitHub App

If you already created a GitHub App in GitHub.com or GHES, you can connect it directly in Mistle.

Configure these values in GitHub:

1. **GitHub App name** (eg. `Mistle GitHub App`)

2. **Homepage URL** - Any valid URL for your organization

3. **Callback URL** - Not necessary. Omit.

4. **Webhook secret**: create a secret that you will also enter in Mistle

5. **Permissions** - consider the following permissions in **Repository Permissions**:

   | Permission    | Access         | Enables                                                                                               |
   | ------------- | -------------- | ----------------------------------------------------------------------------------------------------- |
   | Actions       | Read and write | Trigger runs.<br />Rerun/cancel runs.<br />Inspect workflow runs and artifacts.                       |
   | Checks        | Read-only      | Read check runs.                                                                                      |
   | Contents      | Read and write | Clone/fetch repos.<br />Branch, commit, push.<br />Open PRs from branches.<br />Create releases/tags. |
   | Issues        | Read and write | Create issues.<br />Update issues.<br />Comment on issues.                                            |
   | Metadata      | Read-only      | List repos.<br />Read basic repo context.                                                             |
   | Pull requests | Read and write | Open/update PRs.<br />Request reviewers.<br />Comment/review PRs.<br />Merge PRs (repo rules apply).  |

6. In **Organization Permissions**, enable **Members** with **Read-only** access when the app should sync GitHub teams for review-request trigger filters.

7. In **Organization Permissions**, enable **Organization administration** with **Read-only** access when the app should sync GitHub App bots from installed apps in organizations with accessible repositories.

8. If this app will be used for GitHub account linking, enable the **Email addresses** user permission with **Read-only** access.

9. For **Subscribe to events**, enable the events you want Mistle to take action on. This can be changed later.

10. **Private key** - Generate and download a PEM private key from GitHub App settings.

### Connect The Existing App In Mistle

Open **Integrations** in the dashboard, choose the GitHub target, then select **GitHub App installation**.

Enter:

| Field               | Value                                              |
| ------------------- | -------------------------------------------------- |
| App ID              | GitHub App ID                                      |
| App slug            | GitHub App slug                                    |
| Client ID           | GitHub App client ID                               |
| App private key PEM | GitHub App private key PEM                         |
| Webhook secret      | Shared webhook secret configured on the GitHub App |

`Client ID` is required when this connection will be used for Identity Linking. Installation-only GitHub App usage does not require linked-user authorization.

Installation ID and setup action are stored automatically after the installation flow completes. You do not enter those manually.
App slug must be the actual GitHub App slug from GitHub, not a display name guess.

### Copy The URLs From Mistle Into GitHub

After you create the GitHub App connection, open that connection's detail page in Mistle and copy:

* Webhook callback URL
* Post-installation setup URL

Copy those values directly into your GitHub App settings:

1. Set the GitHub App's **Webhook URL** to Mistle's **Webhook callback URL**.
2. Set the GitHub App's **Setup URL** to Mistle's **Post-installation setup URL**.
3. Ensure the webhook is active in GitHub.

<Frame>
  <img alt="GitHub App connection detail page showing installation, authentication, synced resources, and webhook URL" />
</Frame>

Return to Mistle and click **Install GitHub App**.

## Option 2: Connect With An API Key

API key gives access to the GitHub resources available to that token, but it does not support webhook events from GitHub.

Create a GitHub personal access token or other API token with the scopes your workflows need, then create the Mistle connection with:

| Field   | Value        |
| ------- | ------------ |
| API key | GitHub token |

To sync GitHub teams for review-request trigger filters, the token must be able to read organization members for each organization whose teams should be listed. To sync GitHub App bots, the token must be able to read organization administration for each organization whose installed apps should be listed.

## GitHub Enterprise Server

`github-enterprise-server` is currently only supported for self-hosted deployments.
It is also not enabled by default in the repository's example target manifest.

## Official References

* [Registering a GitHub App](https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/registering-a-github-app)
* [Managing private keys for GitHub Apps](https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps)
* [Managing personal access tokens](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)


# Google Analytics
Source: https://docs.mistle.dev/guides/google-analytics-integration-setup

Connect Google Analytics to Mistle

## Overview

Connect Google Analytics by authorizing Mistle with a Google OAuth client that you create in Google Cloud.

Mistle uses the OAuth authorization code flow to obtain Google access tokens. The local Google Analytics MCP server runs inside the sandbox runtime boundary and calls the Google Analytics Admin API and Google Analytics Data API through Mistle-managed egress, where Mistle injects the connected OAuth token into those outbound requests.

The Google Analytics integration is read-only. Mistle requests only this OAuth scope:

* `https://www.googleapis.com/auth/analytics.readonly`

## Prerequisites

Before connecting Google Analytics:

1. Create or choose a Google Analytics 4 property.
2. Make sure the Google account that will authorize Mistle has access to that Analytics account or property.
3. Create or choose a Google Cloud project that will own the OAuth client.
4. If your Google Auth Platform app is in testing mode, add the authorizing Google account as a test user.

## Enable Google Analytics APIs

Enable the Google Analytics Admin API and Google Analytics Data API in the Google Cloud project that owns the OAuth client:

```bash theme={null}
gcloud services enable \
  analyticsadmin.googleapis.com \
  analyticsdata.googleapis.com \
  --project=PROJECT_ID
```

Replace `PROJECT_ID` with the Google Cloud project ID.

## Configure OAuth Consent

In **Google Auth Platform**, configure branding, audience, and data access for the OAuth app.

Add this scope:

* `https://www.googleapis.com/auth/analytics.readonly`

For an internal Workspace rollout, select **Internal** audience when available. For an external app in testing mode, add every authorizing Google account as a test user before connecting.

## Create A Google OAuth Client

Create a Web application OAuth client in Google Auth Platform.

1. In Mistle, open **Integrations** and choose **Google Analytics**.
2. Copy the **callback URL** shown by Mistle.
3. In Google Cloud, open **Google Auth Platform > Clients**.
4. Create an OAuth client with **Application type** set to **Web application**.
5. Add the Mistle callback URL to **Authorized redirect URIs**.
6. Create the client and copy its **Client ID** and **Client secret**.
7. Return to Mistle, enter the client ID and client secret, and click **Connect Google Analytics**.
8. Complete the Google consent flow with the Google account that should back the connection.

## Connect Google Analytics To A Sandbox Profile

After the Google Analytics connection is active:

1. Open the sandbox profile that should use Google Analytics.
2. Add the Google Analytics integration connection to the profile.
3. In **Resources & Tools**, select the Google Analytics MCP server.
4. Publish the profile version.

Sessions using that published profile can inspect account summaries, properties, metadata, compatibility checks, reports, realtime reports, funnel reports, and Google Ads links through the read-only Google Analytics MCP tools.

## Access Boundary

The OAuth scope lets Mistle read Google Analytics data that the connected Google user can already access. It does not grant write access to Analytics configuration, Measurement Protocol ingestion, or Google Ads management.

For least privilege, authorize Mistle with a Google account that has access only to the Analytics accounts and properties agents should inspect.

## Official References

* [Google Analytics Admin API](https://developers.google.com/analytics/devguides/config/admin/v1)
* [Google Analytics Data API](https://developers.google.com/analytics/devguides/reporting/data/v1)
* [Google Analytics API scopes](https://developers.google.com/analytics/devguides/config/admin/v1/authorization)
* [OAuth 2.0 for Web Server Applications](https://developers.google.com/identity/protocols/oauth2/web-server)


# Google Business Profile
Source: https://docs.mistle.dev/guides/google-business-profile-integration-setup

Connect Google Business Profile to Mistle

## Overview

Connect Google Business Profile by authorizing Mistle with a Google OAuth client that you create in Google Cloud.

Mistle uses the OAuth authorization code flow to obtain Google access tokens. The local Google Business Profile MCP server runs inside the sandbox runtime boundary and calls Google Business Profile APIs through Mistle-managed egress, where Mistle injects the connected OAuth token into outbound requests.

This integration is a thin wrapper around Google's Business Profile APIs. The connected Google account, Business Profile access, API approval status, and OAuth scopes determine what agents can read or change. Mistle stores the token for the connection and routes tool traffic through managed egress.

Mistle requests this OAuth scope:

* `https://www.googleapis.com/auth/business.manage`

## Prerequisites

Before connecting Google Business Profile:

1. Create or choose a Google Business Profile account and location.
2. Make sure the Google account that will authorize Mistle has the required access to that Business Profile.
3. Create or choose a Google Cloud project that will own the OAuth client.
4. Request and receive Google Business Profile API access for the Google Cloud project. Projects without Business Profile API approval may receive quota or access errors from Google.
5. If your Google Auth Platform app is in testing mode, add the authorizing Google account as a test user.

## Enable The Business Profile APIs

Enable the relevant Business Profile APIs in the Google Cloud project that owns the OAuth client:

```bash theme={null}
gcloud services enable \
  mybusinessaccountmanagement.googleapis.com \
  mybusinessbusinessinformation.googleapis.com \
  businessprofileperformance.googleapis.com \
  mybusiness.googleapis.com \
  --project=PROJECT_ID
```

Replace `PROJECT_ID` with the Google Cloud project ID.

## Configure OAuth Consent

In **Google Auth Platform**, configure branding, audience, and data access for the OAuth app.

Add this scope:

* `https://www.googleapis.com/auth/business.manage`

For an internal Workspace rollout, select **Internal** audience when available. For an external app in testing mode, add every authorizing Google account as a test user before connecting.

## Create A Google OAuth Client

Create a Web application OAuth client in Google Auth Platform.

1. In Mistle, open **Integrations** and choose **Google Business Profile**.
2. Copy the **callback URL** shown by Mistle.
3. In Google Cloud, open **Google Auth Platform > Clients**.
4. Create an OAuth client with **Application type** set to **Web application**.
5. Add the Mistle callback URL to **Authorized redirect URIs**.
6. Create the client and copy its **Client ID** and **Client secret**.
7. Return to Mistle, enter the client ID and client secret, and click **Connect Google Business Profile**.
8. Complete the Google consent flow with the Google account that should back the connection.

## Connect Google Business Profile To A Sandbox Profile

After the Google Business Profile connection is active:

1. Open the sandbox profile that should use Google Business Profile.
2. Add the Google Business Profile integration connection to the profile.
3. In **Resources & Tools**, select the Google Business Profile MCP server.
4. Publish the profile version.

Sessions using that published profile can inspect and manage Business Profile accounts, locations, reviews, media, local posts, and performance metrics through the Google Business Profile MCP tools.

## Access Boundary

The OAuth scope lets Mistle use Google Business Profile APIs as the connected Google user. It does not bypass Google account permissions, Business Profile role assignments, Google Cloud API enablement, API approval, or Google quotas.

For least privilege, authorize Mistle with a Google account that has access only to the Business Profile accounts and locations agents should manage.

## Official References

* [Business Profile APIs](https://developers.google.com/my-business)
* [Account Management API](https://developers.google.com/my-business/reference/accountmanagement/rest)
* [Business Information API](https://developers.google.com/my-business/reference/businessinformation/rest)
* [Business Profile Performance API](https://developers.google.com/my-business/reference/performance/rest)
* [OAuth 2.0 for Web Server Applications](https://developers.google.com/identity/protocols/oauth2/web-server)


# Google Search Console
Source: https://docs.mistle.dev/guides/google-search-console-integration-setup

Connect Google Search Console to Mistle

## Overview

Connect Google Search Console by authorizing Mistle with a Google OAuth client that you create in Google Cloud.

Mistle uses the OAuth authorization code flow to obtain Google access tokens. The local Google Search Console MCP server runs inside the sandbox runtime boundary and calls the Search Console API through Mistle-managed egress, where Mistle injects the connected OAuth token into outbound requests.

The Google Search Console integration is read-only. Mistle requests only this OAuth scope:

* `https://www.googleapis.com/auth/webmasters.readonly`

## Prerequisites

Before connecting Google Search Console:

1. Create or choose a Search Console property.
2. Make sure the Google account that will authorize Mistle has access to that Search Console property.
3. Create or choose a Google Cloud project that will own the OAuth client.
4. If your Google Auth Platform app is in testing mode, add the authorizing Google account as a test user.

## Enable The Search Console API

Enable the Search Console API in the Google Cloud project that owns the OAuth client:

```bash theme={null}
gcloud services enable \
  searchconsole.googleapis.com \
  --project=PROJECT_ID
```

Replace `PROJECT_ID` with the Google Cloud project ID.

## Configure OAuth Consent

In **Google Auth Platform**, configure branding, audience, and data access for the OAuth app.

Add this scope:

* `https://www.googleapis.com/auth/webmasters.readonly`

For an internal Workspace rollout, select **Internal** audience when available. For an external app in testing mode, add every authorizing Google account as a test user before connecting.

## Create A Google OAuth Client

Create a Web application OAuth client in Google Auth Platform.

1. In Mistle, open **Integrations** and choose **Google Search Console**.
2. Copy the **callback URL** shown by Mistle.
3. In Google Cloud, open **Google Auth Platform > Clients**.
4. Create an OAuth client with **Application type** set to **Web application**.
5. Add the Mistle callback URL to **Authorized redirect URIs**.
6. Create the client and copy its **Client ID** and **Client secret**.
7. Return to Mistle, enter the client ID and client secret, and click **Connect Google Search Console**.
8. Complete the Google consent flow with the Google account that should back the connection.

## Connect Google Search Console To A Sandbox Profile

After the Google Search Console connection is active:

1. Open the sandbox profile that should use Google Search Console.
2. Add the Google Search Console integration connection to the profile.
3. In **Resources & Tools**, select the Google Search Console MCP server.
4. Publish the profile version.

Sessions using that published profile can inspect sites, search analytics data, sitemaps, and URL inspection results through the read-only Google Search Console MCP tools.

## Access Boundary

The OAuth scope lets Mistle read Google Search Console data that the connected Google user can already access. It does not grant write access to Search Console site ownership, sitemap submission, indexing requests, or property management.

For least privilege, authorize Mistle with a Google account that has access only to the Search Console properties agents should inspect.

## Official References

* [Search Console API](https://developers.google.com/webmaster-tools)
* [Search Console API reference](https://developers.google.com/webmaster-tools/v1/api_reference_index)
* [URL Inspection API](https://developers.google.com/webmaster-tools/v1/urlInspection.index/inspect)
* [OAuth 2.0 for Web Server Applications](https://developers.google.com/identity/protocols/oauth2/web-server)


# Google Workspace
Source: https://docs.mistle.dev/guides/google-workspace-integration-setup

Connect Google Workspace tools to Mistle

## Overview

Connect to Google Workspace by authorizing Mistle with a Google OAuth client or service account that you create in Google Cloud.

Mistle uses the configured connection to obtain Google access tokens, then injects those tokens into the Workspace tools selected in a sandbox profile. Gmail, Drive, Sheets, Docs, Slides, Calendar, Chat, and People use Mistle's local `gws` tool wrapper around the official Google REST APIs.

## Enable Google Workspace APIs

Use a Google Cloud project owned by the Workspace organization that should authorize the selected Workspace tools.

Enable the Workspace product APIs needed by the selected tools:

```bash theme={null}
gcloud services enable \
  gmail.googleapis.com \
  drive.googleapis.com \
  sheets.googleapis.com \
  docs.googleapis.com \
  slides.googleapis.com \
  calendar-json.googleapis.com \
  chat.googleapis.com \
  people.googleapis.com \
  --project=PROJECT_ID
```

Replace `PROJECT_ID` with the Google Cloud project ID.

## Configure Google Chat

If you enable the Google Chat tools, configure a Chat app in the same Google Cloud project:

1. Open **Google Chat API > Manage > Configuration**.
2. Set **App name** to `Chat MCP`.
3. Set **Avatar URL** to `https://developers.google.com/chat/images/quickstart-app-avatar.png`.
4. Set **Description** to `Chat MCP server`.
5. Turn off **Enable interactive features**.
6. Select **Log errors to Logging**.
7. Save the configuration.

## Configure OAuth Consent

In **Google Auth Platform**, configure branding, audience, and data access for the OAuth app.

For an internal Workspace rollout, select **Internal** audience when available. For an external app in testing mode, add every authorizing Google account as a test user before connecting.

Add the OAuth scopes for the Workspace tools you intend to use. Mistle currently requests a fixed scope set for the supported Workspace tools:

* `https://www.googleapis.com/auth/gmail.readonly`
* `https://www.googleapis.com/auth/gmail.compose`
* `https://www.googleapis.com/auth/drive`
* `https://www.googleapis.com/auth/spreadsheets`
* `https://www.googleapis.com/auth/documents`
* `https://www.googleapis.com/auth/presentations`
* `https://www.googleapis.com/auth/calendar.calendarlist.readonly`
* `https://www.googleapis.com/auth/calendar.events.freebusy`
* `https://www.googleapis.com/auth/calendar.events.readonly`
* `https://www.googleapis.com/auth/calendar.events`
* `https://www.googleapis.com/auth/chat.spaces.readonly`
* `https://www.googleapis.com/auth/chat.memberships.readonly`
* `https://www.googleapis.com/auth/chat.messages.readonly`
* `https://www.googleapis.com/auth/chat.messages.create`
* `https://www.googleapis.com/auth/chat.users.readstate.readonly`
* `https://www.googleapis.com/auth/directory.readonly`
* `https://www.googleapis.com/auth/userinfo.profile`
* `https://www.googleapis.com/auth/contacts.readonly`

## Create A Google OAuth Client

Create a Web application OAuth client in Google Auth Platform.

1. In Mistle, open **Integrations** and choose **Google Workspace**.
2. Copy the **callback URL** shown by Mistle.
3. In Google Cloud, open **Google Auth Platform > Clients**.
4. Create an OAuth client with **Application type** set to **Web application**.
5. Add the Mistle callback URL to **Authorized redirect URIs**.
6. Create the client and copy its **Client ID** and **Client secret**.
7. Return to Mistle, enter the client ID and client secret, and click **Connect Google Workspace**.
8. Complete the Google consent flow with the Google account that should back the connection.

## Connect With A Service Account

For headless Workspace automation, you can connect with a Google Cloud service account. This lets Mistle mint short-lived Google access tokens without an interactive OAuth consent flow.

<Note>
  Domain-wide delegation is optional. Leave the sandbox profile's Workspace user email blank to mint
  tokens as the service account itself. Enter a Workspace user email only when the service account
  is configured for domain-wide delegation and should impersonate that user.
</Note>

To use a service account connection:

1. Create a Google Cloud service account in the same project used for the Workspace APIs.
2. If you need domain-wide delegation, enable it in the service account details and copy the service account **Client ID**.
3. If you enabled domain-wide delegation, open **Google Workspace Admin Console > Security > Access and data control > API controls > Manage Domain Wide Delegation**.
4. If you enabled domain-wide delegation, click **Add new**, paste the service account Client ID, and authorize the full fixed Mistle OAuth scope set listed in **Configure OAuth Consent**.
5. In Google Cloud, create a JSON key for the service account and store it carefully.
6. In Mistle, choose **Service account** when adding a Google Workspace connection.
7. Paste the service account JSON key.

Mistle signs a Google OAuth JWT bearer assertion with the service account key, exchanges it for a short-lived Google access token, and injects that token into calls to the selected Workspace tools.

## Connect MCP Servers To A Sandbox Profile

After the Google Workspace connection is active:

1. Open the sandbox profile that should use Google Workspace.
2. Add the Google Workspace integration connection to the profile.
3. In **Resources & Tools**, select the Google Workspace tools that agents may use.
4. For service account connections, optionally enter the **Workspace user email** Mistle should use as the Google Workspace user subject when minting access tokens with domain-wide delegation.
5. Publish the profile version.

Only selected tools are exposed to sessions using that published profile.

## Supported Tools

| Tool            | Runtime path                                  |
| --------------- | --------------------------------------------- |
| Gmail           | Local `gws` MCP wrapper for Gmail REST API    |
| Google Drive    | Local `gws` MCP wrapper for Drive REST API    |
| Google Sheets   | Local `gws` MCP wrapper for Sheets REST API   |
| Google Docs     | Local `gws` MCP wrapper for Docs REST API     |
| Google Slides   | Local `gws` MCP wrapper for Slides REST API   |
| Google Calendar | Local `gws` MCP wrapper for Calendar REST API |
| Google Chat     | Local `gws` MCP wrapper for Chat REST API     |
| People API      | Local `gws` MCP wrapper for People REST API   |

## Official References

* [OAuth 2.0 for Web Server Applications](https://developers.google.com/identity/protocols/oauth2/web-server)
* [Using OAuth 2.0 for Server to Server Applications](https://developers.google.com/identity/protocols/oauth2/service-account)
* [Control API access with domain-wide delegation](https://knowledge.workspace.google.com/admin/apps/control-api-access-with-domain-wide-delegation)


# Google Ads
Source: https://docs.mistle.dev/guides/googleads-integration-setup

Connect Google Ads to Mistle

## Overview

Connect Google Ads by authorizing Mistle with a Google OAuth client and providing a Google Ads developer token.

Mistle uses the OAuth authorization code flow to obtain Google access tokens. The local Google Ads CLI and MCP server run inside the sandbox runtime boundary and call the Google Ads API through Mistle-managed egress, where Mistle injects the refreshed OAuth access token and encrypted developer token into outbound requests.

This integration is a thin wrapper around the Google Ads API. The connected Google user, OAuth scopes, developer token approval, and Google Ads account access determine what agents can read or change. Mistle does not grant, inspect, or enforce Google Ads permissions beyond storing connection credentials and routing tool traffic through managed egress.

## Prerequisites

Before connecting Google Ads:

1. Create or choose a Google Ads manager or client account.
2. Create or choose a Google Cloud project that will own the OAuth client.
3. Enable the Google Ads API for that project.
4. Make sure the Google account that authorizes Mistle has access to the Google Ads accounts agents should use.
5. Create or choose a Google Ads developer token.
6. If your Google Auth Platform app is in testing mode, add the authorizing Google account as a test user.

## Configure OAuth Consent

In Google Auth Platform, configure branding, audience, and data access for the OAuth app.

Add this scope:

* `https://www.googleapis.com/auth/adwords`

For an internal Workspace rollout, select **Internal** audience when available. For an external app in testing mode, add every authorizing Google account as a test user before connecting.

## Create A Google OAuth Client

Create a Web application OAuth client in Google Auth Platform.

1. In Mistle, open **Integrations** and choose **Google Ads**.
2. Copy the **callback URL** shown by Mistle.
3. In Google Cloud, open **Google Auth Platform > Clients**.
4. Create an OAuth client with **Application type** set to **Web application**.
5. Add the Mistle callback URL to **Authorized redirect URIs**.
6. Create the client and copy its **Client ID** and **Client secret**.

## Connect Google Ads In Mistle

Return to Mistle and enter:

| Field               | Value                          |
| ------------------- | ------------------------------ |
| OAuth client ID     | Google OAuth web client ID     |
| OAuth client secret | Google OAuth web client secret |
| Developer token     | Google Ads developer token     |

Then click **Connect Google Ads** and complete the Google consent flow with the Google account that should back the connection.

Mistle stores the OAuth client secret, access token, refresh token, and developer token as encrypted connection credentials. The developer token is not stored in connection config.

## Connect Google Ads To A Sandbox Profile

After the Google Ads connection is active:

1. Open the sandbox profile that should use Google Ads.
2. Add the Google Ads integration connection to the profile.
3. In **Resources & Tools**, select the Google Ads CLI, Google Ads MCP server, or both.
4. Publish the profile version.

Sessions using that published profile can use named Google Ads commands and MCP tools for common workflows, plus raw Google Ads API request tools for full endpoint coverage exposed by the Mistle Google Ads wrapper.

When a Google Ads call needs a manager account context, pass the manager customer ID on that specific CLI command or MCP tool call with `--login-customer-id` / `login_customer_id`. It is a request routing header, not an OAuth authorization setting.

## Local Wrapper Decision

Google documents a Google Ads MCP server, but the Mistle integration uses the pinned `mistlehq/tools` Google Ads CLI/MCP binary. That keeps the runtime shape consistent with other Mistle thin-wrapper integrations, lets Mistle inject credentials through managed egress, and keeps full API coverage available through raw Google Ads API request commands/tools.

## API Version

The target defaults to Google Ads API `v24`. Operators can pin a different supported version with `api_version` in the integration target config.

## Self-Hosted Target Config

Self-hosted deployments can enable `googleads-default` with an empty config:

```json theme={null}
{
  "targetKey": "googleads-default",
  "enabled": true,
  "config": {}
}
```

Set `api_version` only when your deployment needs to pin a different supported Google Ads API version:

```json theme={null}
{
  "targetKey": "googleads-default",
  "enabled": true,
  "config": {
    "api_version": "v24"
  }
}
```

## Official References

* [Google Ads API](https://developers.google.com/google-ads/api/docs/start)
* [Google Ads API call structure](https://developers.google.com/google-ads/api/docs/concepts/call-structure)
* [Google Ads API versioning](https://developers.google.com/google-ads/api/docs/concepts/versioning)
* [Google Ads developer tokens](https://developers.google.com/google-ads/api/docs/api-policy/developer-token)
* [Secure your Google Ads API credentials](https://developers.google.com/google-ads/api/docs/productionize/secure-credentials)
* [OAuth 2.0 for Web Server Applications](https://developers.google.com/identity/protocols/oauth2/web-server)
* [Google Ads MCP server](https://developers.google.com/google-ads/api/docs/developer-toolkit/mcp-server)


# Inception Labs
Source: https://docs.mistle.dev/guides/inception-integration-setup

Connect Inception Labs model access to Mistle

## Overview

Inception Labs provides model access for sandbox profiles that use OpenCode-compatible agent runtimes.

Use this connection when a profile should call Inception Labs models through an API key managed by Mistle.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Inception Labs**, then select **API key**.

Enter:

| Field   | Value                  |
| ------- | ---------------------- |
| API key | Inception Labs API key |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use Inception Labs.
2. Add Inception Labs as a model provider connection.
3. Save and publish the profile version.


# Integrations
Source: https://docs.mistle.dev/guides/integrations

Connect external systems and model providers to Mistle

## Overview

Integrations let agents interact with external systems without placing long-lived credentials inside the sandboxes where agents perform tasks.

For example, integrations can let an agent:

* respond in Slack
* work in GitHub and open pull requests
* inspect logs and traces in Datadog, Sentry, or SigNoz
* read or update issues in Jira or Linear
* call model providers such as OpenAI, Anthropic, OpenRouter, or OpenCode Go
* run sandboxes through runtime providers such as E2B, Modal, OpenComputer, or Tensorlake

## Recommended Starting Integrations

Most useful Mistle workflows need at least:

* [OpenAI](/guides/openai-integration-setup), so agents can call model APIs.
* [GitHub](/guides/github-integration-setup), so agents can inspect repositories, make changes, and open pull requests.

Other integrations are optional and should match the systems where your team wants agents to receive context, take action, or report results.

Profiles that use OpenCode-compatible agent runtimes can use model provider connections such as [Anthropic](/guides/anthropic-integration-setup), [DeepSeek](/guides/deepseek-integration-setup), [Fireworks AI](/guides/fireworks-integration-setup), [Kimi](/guides/kimi-integration-setup), [OpenRouter](/guides/openrouter-integration-setup), and [OpenCode Go](/guides/opencode-go-integration-setup).

## After Connecting Integrations

Creating an integration connection makes the provider available to Mistle, but sessions use the integrations configured on their sandbox profile.

After connecting a provider:

1. Open the sandbox profile that should use it.
2. Add or update the profile's integration configuration.
3. Publish the profile version.
4. Start a session from that published profile.

Read [Sandbox Profiles](/guides/sandbox-profiles) for the profile publishing flow.

## Credentials

Integrations let teams manage credentials and access centrally. Secrets are encrypted with organization-scoped keys and protected by master encryption keys unique to each Mistle deployment.

Sandboxes are credentialless by default. When an agent needs a connected service, requests go through Mistle-controlled services that resolve and apply the right credentials outside the sandbox.

## Provider Tools

When possible, Mistle installs official provider tools in sandboxes so agents can use provider-supported interfaces.

When an official tool is unavailable or not well suited for agent workflows, Mistle uses maintained CLI tools built for those integrations. Those tools live in [mistlehq/tools](https://github.com/mistlehq/tools).

## Supported Integrations

Mistle currently ships setup guides for these external system connectors:

* [AgentMail](/guides/agentmail-integration-setup)
* [Autumn](/guides/autumn-integration-setup)
* [AWS](/guides/aws-integration-setup)
* [BugSnag](/guides/bugsnag-integration-setup)
* [Cloudflare](/guides/cloudflare-integration-setup)
* [DataForSEO](/guides/dataforseo-integration-setup)
* [Datadog](/guides/datadog-integration-setup)
* [Expo](/guides/expo-integration-setup)
* [Google Cloud](/guides/gcp-integration-setup)
* [Google Analytics](/guides/google-analytics-integration-setup)
* [Google Business Profile](/guides/google-business-profile-integration-setup)
* [Google Search Console](/guides/google-search-console-integration-setup)
* [Google Workspace](/guides/google-workspace-integration-setup)
* [GitHub](/guides/github-integration-setup)
* [Jira](/guides/jira-integration-setup)
* [Klaviyo](/guides/klaviyo-integration-setup)
* [Linear](/guides/linear-integration-setup)
* [Meta Ads](/guides/metaads-integration-setup)
* [Notion](/guides/notion-integration-setup)
* [PlanetScale](/guides/planetscale-integration-setup)
* [PostHog](/guides/posthog-integration-setup)
* [Railway](/guides/railway-integration-setup)
* [Render](/guides/render-integration-setup)
* [Resend](/guides/resend-integration-setup)
* [Sentry](/guides/sentry-integration-setup)
* [SigNoz](/guides/signoz-integration-setup)
* [Slack](/guides/slack-integration-setup)
* [Stripe](/guides/stripe-integration-setup)
* [Supabase](/guides/supabase-integration-setup)
* [Telegram](/guides/telegram-integration-setup)

Mistle also ships setup guides for these model provider connections:

* [Anthropic](/guides/anthropic-integration-setup)
* [DeepSeek](/guides/deepseek-integration-setup)
* [Fireworks AI](/guides/fireworks-integration-setup)
* [Inception Labs](/guides/inception-integration-setup)
* [Kimi](/guides/kimi-integration-setup)
* [MiniMax](/guides/minimax-integration-setup)
* [OpenAI](/guides/openai-integration-setup)
* [OpenCode Go](/guides/opencode-go-integration-setup)
* [OpenRouter](/guides/openrouter-integration-setup)
* [Z.ai](/guides/zai-integration-setup)

And these sandbox runtime connection guides:

* [E2B](/guides/e2b-integration-setup)
* [Modal](/guides/modal-integration-setup)
* [OpenComputer](/guides/opencomputer-integration-setup)
* [Tensorlake](/guides/tensorlake-integration-setup)

## Next Steps

* Read [Account Linking](/guides/account-linking) when provider identities should map back to Mistle users.
* Read [Triggers](/guides/triggers) when provider events should trigger agent work.
* For self-hosted deployments, read [Self-Hosted Integrations Overview](/guides/self-hosted-integrations-overview).


# Jira
Source: https://docs.mistle.dev/guides/jira-integration-setup

Connect Jira to Mistle

## Overview

Jira can be connected in three ways:

* Personal API token
* Service account API token
* Service account OAuth client credentials

Use Personal API token when the connection should access Jira as a user account.
Use a service account token or OAuth client credentials when the connection should access Jira as a service account.

## Option 1: Personal API Token

Personal API token gives access to Jira as that Atlassian user and is the only Jira option that currently supports managed webhook registration.

Create an Atlassian API token for that user at [Atlassian API tokens](https://id.atlassian.com/manage-profile/security/api-tokens), then connect in Mistle with:

| Field              | Value                                                      |
| ------------------ | ---------------------------------------------------------- |
| Site URL           | Jira Cloud site URL like `https://your-site.atlassian.net` |
| Email              | Atlassian account email                                    |
| Personal API token | Atlassian API token                                        |

## Option 2: Service Account API Token

Service account API token gives access to Jira as a service account by using a scoped Atlassian API token.

Create a service account and a scoped API token, then connect in Mistle with:

| Field                     | Value                     |
| ------------------------- | ------------------------- |
| Cloud ID                  | Jira Cloud ID             |
| Service account API token | Service account API token |

This option uses Cloud ID, not a site URL. Atlassian's scoped service-account tokens use the `api.atlassian.com/ex/jira/<cloudId>/...` API shape, so make sure you collect the cloud ID before connecting.

## Option 3: Service Account OAuth Client Credentials

Service account OAuth client credentials gives access to Jira as a service account by exchanging a client ID and client secret for access tokens.

Create Atlassian OAuth 2.0 credentials for the service account, then connect in Mistle with:

| Field         | Value                         |
| ------------- | ----------------------------- |
| Cloud ID      | Jira Cloud ID                 |
| Client ID     | Atlassian OAuth client ID     |
| Client secret | Atlassian OAuth client secret |

## Webhooks

Managed webhook registration is currently supported only for **personal API token** connections.

After the connection exists, use the **Webhooks** section on that connection. The product already shows the callback URL to copy into Jira, and the managed webhook registration can be created from there.

## Jira Cloud

The current Jira integration is Jira Cloud only.
The connection schemas require Atlassian Cloud values such as `*.atlassian.net` site URLs and Cloud ID.

## Official References

* [Atlassian API tokens](https://id.atlassian.com/manage-profile/security/api-tokens)
* [Manage API tokens for service accounts](https://support.atlassian.com/user-management/docs/manage-api-tokens-for-service-accounts/)
* [Create OAuth 2.0 credentials for service accounts](https://support.atlassian.com/user-management/docs/create-oauth-2-0-credential-for-service-accounts/)


# Kimi
Source: https://docs.mistle.dev/guides/kimi-integration-setup

Connect Kimi model access to Mistle

## Overview

Kimi provides model access for sandbox profiles that use OpenCode-compatible agent runtimes.

Use this connection when a profile should call Kimi models through an API key managed by Mistle.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Kimi**, then select **API key**.

Enter:

| Field   | Value        |
| ------- | ------------ |
| API key | Kimi API key |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use Kimi.
2. Add Kimi as a model provider connection.
3. Save and publish the profile version.


# Klaviyo
Source: https://docs.mistle.dev/guides/klaviyo-integration-setup

Connect Klaviyo to Mistle

## Overview

Connect to Klaviyo through Klaviyo hosted MCP OAuth.

The Klaviyo integration exposes hosted MCP access through Klaviyo's official remote MCP server.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Klaviyo**, then select **Klaviyo MCP OAuth**.

The browser redirects to Klaviyo, the user approves access, and the returned OAuth credentials are stored for the connection.

There are no user-entered secret fields for this target.

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use Klaviyo.
2. Add Klaviyo to the profile's integration configuration.
3. Select the Klaviyo MCP tool.
4. Save and publish the profile version.

## Official Reference

* [Klaviyo MCP server](https://developers.klaviyo.com/en/docs/model_context_protocol_mcp_server)

This integration uses the hosted MCP server at `https://mcp.klaviyo.com/mcp`.


# Linear
Source: https://docs.mistle.dev/guides/linear-integration-setup

Connect Linear to Mistle

## Overview

Connect to Linear by providing a personal API key for the user account that should back the connection.

## Create A Linear API Key

Create a Linear personal API key for the user account that should back the Mistle connection.
Use a workspace admin account when you want Mistle to automatically register Linear webhooks for
triggers.

According to Linear's docs:

* admins can control whether members are allowed to create their own API keys
* existing API keys can be viewed and revoked from `Settings > Administration > API`
* admins and permitted members can create personal API keys from `Settings > Account > Security & Access`
* creating or managing webhooks requires a workspace admin API key or an OAuth app with admin scope

When creating the key, Linear lets you choose either full access or restricted permissions, and you can limit the key to specific teams.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Linear**, then select **API key**.

Enter:

| Field   | Value          |
| ------- | -------------- |
| API key | Linear API key |

## Webhook Coverage

Mistle currently registers Linear webhooks for **all public teams** in the workspace. Linear
private teams are not included in that workspace-wide public-team webhook scope.

To receive events from a Linear private team, Linear requires a team-scoped webhook for that
specific team. Mistle does not yet expose private-team webhook selection in the dashboard.

## Official References

* [Linear API and Webhooks](https://linear.app/docs/api-and-webhooks)
* [Linear Private Teams](https://linear.app/docs/private-teams)
* [Linear Security & Access](https://linear.app/docs/security-and-access)


# Meta Ads
Source: https://docs.mistle.dev/guides/metaads-integration-setup

Connect Meta Ads to Mistle

## Overview

Connect Meta Ads by providing a Meta access token. Mistle uses the token to route the bundled Meta Ads CLI and MCP server through the Meta Marketing API.

This integration is a thin wrapper around Meta's APIs. The token's Meta app, business, user, system-user, and ad-account permissions determine what agents can read or change. Mistle does not grant, inspect, or enforce Meta permissions beyond storing the token for the connection and routing tool traffic through managed egress.

## Configuring Meta Access

Before creating the connection, make sure:

1. You have access to the Meta business, app, user, or system user that owns the token.
2. The token is allowed to access the ad accounts and Marketing API operations you want agents to use.
3. Write permissions are granted in Meta when agents should create, update, or delete Meta Ads resources.

If Meta rejects a request because the token is missing access, Mistle surfaces the Meta API error to the agent.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Meta Ads**, then select **Access token**.

Enter:

| Field        | Value             |
| ------------ | ----------------- |
| Access token | Meta access token |

## Using The Tools

After the connection is added to a sandbox profile, agents can use:

* the Meta Ads CLI for named commands and raw Graph API requests
* the Meta Ads MCP server for discoverable tool calls

The raw Graph API request command and tool are the complete API coverage surface. Named commands and tools provide progressive discovery for common Marketing API workflows such as ad accounts, campaigns, ad sets, ads, creatives, insights, and targeting search.

## Self-Hosted Target Config

Self-hosted deployments can enable `metaads-default` with an empty config:

```json theme={null}
{
  "targetKey": "metaads-default",
  "enabled": true,
  "config": {}
}
```

By default, the integration uses Meta Graph API `v25.0`. Operators can set `graph_api_version` when a deployment must pin a different supported Meta Graph API version:

```json theme={null}
{
  "targetKey": "metaads-default",
  "enabled": true,
  "config": {
    "graph_api_version": "v25.0"
  }
}
```

## Official References

* [Meta Marketing APIs](https://developers.facebook.com/docs/marketing-apis/)
* [Meta Graph API](https://developers.facebook.com/docs/graph-api/)
* [Meta access tokens](https://developers.facebook.com/docs/facebook-login/guides/access-tokens/)


# MiniMax
Source: https://docs.mistle.dev/guides/minimax-integration-setup

Connect MiniMax model access to Mistle

## Overview

MiniMax provides model access for sandbox profiles that use OpenCode-compatible agent runtimes.

Use this connection when a profile should call MiniMax models through an API key managed by Mistle.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **MiniMax**, then select **API key**.

Enter:

| Field   | Value           |
| ------- | --------------- |
| API key | MiniMax API key |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use MiniMax.
2. Add MiniMax as a model provider connection.
3. Save and publish the profile version.


# Modal
Source: https://docs.mistle.dev/guides/modal-integration-setup

Connect Modal sandbox runtime access to Mistle

## Overview

Modal provides a sandbox runtime for running Mistle sandboxes with organization-owned Modal credentials.

Use this connection when a sandbox profile should use workspace-owned Modal credentials.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Modal**, then select **Token**.

Enter:

| Field        | Value              |
| ------------ | ------------------ |
| Token ID     | Modal token ID     |
| Token secret | Modal token secret |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should run on Modal.
2. Choose **Modal** as the sandbox runtime.
3. Select the Modal credentials connection.
4. Save and publish the profile version.

For self-hosted deployments, the Modal runtime must also be enabled in deployment configuration before profiles can use it.


# Notion
Source: https://docs.mistle.dev/guides/notion-integration-setup

Connect Notion to Mistle

## Overview

Connect to Notion through Notion hosted MCP OAuth.

The Notion integration exposes hosted MCP access for workspace search, pages, databases, and comments.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Notion**, then select **Notion MCP OAuth**.

The browser redirects to Notion, the user approves access, and the returned OAuth credentials are stored for the connection.

There are no user-entered secret fields for this target.

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use Notion.
2. Add Notion to the profile's integration configuration.
3. Select the Notion MCP tool.
4. Save and publish the profile version.


# OpenAI
Source: https://docs.mistle.dev/guides/openai-integration-setup

Connect OpenAI to Mistle

## Overview

OpenAI can be connected in two ways:

* API key
* ChatGPT subscription

Use API key when the connection should access OpenAI through an API credential.
Use ChatGPT subscription when the user should sign in interactively through ChatGPT instead.

Model and reasoning capability policy for this target is managed at the target level rather than per connection.

## Option 1: API Key

API key gives access to OpenAI through the API key you provide.

Create an OpenAI API key, then connect in Mistle with:

| Field   | Value          |
| ------- | -------------- |
| API key | OpenAI API key |

## Option 2: ChatGPT Subscription

ChatGPT subscription gives access through an interactive ChatGPT sign-in flow instead of a user-entered API key.

Open **Integrations** in the dashboard, choose **OpenAI**, then select **ChatGPT subscription**.

The product starts a device-authorization flow and asks the user to:

1. Open the verification link.
2. Enter the device code.
3. Approve access in ChatGPT.

No operator-managed OAuth client registration is exposed for this flow. The device-code flow is built into the current OpenAI integration implementation.

## Official References

* [How to create and use an API key](https://help.openai.com/en/articles/4936850-how-to-create-and-use-an-api-key)
* [Assign API key permissions](https://help.openai.com/en/articles/8867743-assign-api-key-permissions)

The ChatGPT subscription notes above are based on the current `device-authorization` implementation. OpenAI's public docs currently document API-key setup much more directly than this device-code flow.


# OpenCode Go
Source: https://docs.mistle.dev/guides/opencode-go-integration-setup

Connect OpenCode Go model access to Mistle

## Overview

OpenCode Go provides model access for sandbox profiles that use the OpenCode agent runtime.

Use this connection when an OpenCode profile should be able to call OpenCode Go through an API key managed by Mistle.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **OpenCode Go**, then select **API key**.

Enter:

| Field   | Value               |
| ------- | ------------------- |
| API key | OpenCode Go API key |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use OpenCode Go.
2. In **Runtime**, set **Agent** to **OpenCode**.
3. Add OpenCode Go as a model provider connection.
4. Save and publish the profile version.

OpenCode Go connections are only available to OpenCode profiles. Codex profiles use OpenAI-compatible model-provider connections instead.


# OpenComputer
Source: https://docs.mistle.dev/guides/opencomputer-integration-setup

Connect OpenComputer sandbox runtime access to Mistle

## Overview

OpenComputer provides a sandbox runtime for running Mistle sandboxes with an organization-owned OpenComputer API key.

Use this connection when a sandbox profile should use workspace-owned OpenComputer credentials.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **OpenComputer**, then select **API key**.

Enter:

| Field   | Value                |
| ------- | -------------------- |
| API key | OpenComputer API key |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should run on OpenComputer.
2. Choose **OpenComputer** as the sandbox runtime.
3. Select the OpenComputer credentials connection.
4. Save and publish the profile version.

For self-hosted deployments, the OpenComputer runtime must also be enabled in deployment configuration before profiles can use it.


# OpenRouter
Source: https://docs.mistle.dev/guides/openrouter-integration-setup

Connect OpenRouter model access to Mistle

## Overview

OpenRouter provides model access for sandbox profiles that use OpenCode-compatible agent runtimes.

Use this connection when a profile should call OpenRouter models through an API key managed by Mistle.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **OpenRouter**, then select **API key**.

Enter:

| Field   | Value              |
| ------- | ------------------ |
| API key | OpenRouter API key |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use OpenRouter.
2. Add OpenRouter as a model provider connection.
3. Save and publish the profile version.


# PlanetScale
Source: https://docs.mistle.dev/guides/planetscale-integration-setup

Connect PlanetScale to Mistle

## Overview

Connect to PlanetScale through a PlanetScale OAuth redirect flow.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **PlanetScale**, then select **PlanetScale OAuth**.

The browser redirects to PlanetScale, the user approves access, and the returned OAuth credentials are stored for the connection.

There are no user-entered secret fields for this target.

## Official References

* [PlanetScale OAuth](https://planetscale.com/docs/api/reference/oauth)

The exact redirect flow in this guide is based on the current PlanetScale integration implementation.


# PostHog
Source: https://docs.mistle.dev/guides/posthog-integration-setup

Connect PostHog to Mistle

## Overview

Connect to PostHog through PostHog's hosted MCP server and PostHog OAuth.

The PostHog MCP server lets agents inspect analytics, query PostHog data, manage feature flags, and investigate errors through the official provider-hosted endpoint.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **PostHog**, then select **PostHog OAuth**.

The browser redirects to PostHog, the user approves access, and the returned OAuth credentials are stored for the connection.

PostHog routes the hosted MCP connection to the correct US or EU data region based on the account that authorizes access.

## Access Scope

This integration requests the PostHog MCP server's read and write OAuth scopes so agents can use the full official MCP workflow.

Review agent tool calls before approving changes that modify PostHog resources such as feature flags, dashboards, issues, surveys, or destinations.

## Official Reference

* [PostHog Model Context Protocol](https://posthog.com/docs/model-context-protocol)
* [PostHog MCP for Codex](https://posthog.com/docs/model-context-protocol/codex)

This integration uses the hosted MCP server at `https://mcp.posthog.com/mcp`.


# Railway
Source: https://docs.mistle.dev/guides/railway-integration-setup

Connect Railway to Mistle

## Overview

Connect to Railway through Railway's hosted MCP server and Railway OAuth.

The Railway MCP server lets agents inspect and operate on Railway workspaces, projects, services, deployments, logs, and variables through the official provider-hosted endpoint.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Railway**, then select **Railway OAuth**.

The browser redirects to Railway, the user approves access, and the returned OAuth credentials are stored for the connection.

## Access Scope

This integration requests Railway's hosted MCP OAuth scopes: `openid`, `profile`, `email`, `offline_access`, and `workspace:member`.

Review agent tool calls before approving changes that redeploy services, accept deployments, change variables, or otherwise modify Railway resources.

## Official References

* [Railway MCP server](https://docs.railway.com/ai/mcp-server)
* [Railway remote MCP announcement](https://blog.railway.com/p/agent-rails-remote-mcp-cli)

This integration uses the hosted MCP server at `https://mcp.railway.com`.


# Render
Source: https://docs.mistle.dev/guides/render-integration-setup

Connect Render to Mistle

## Overview

Connect to Render through Render's hosted MCP server and a Render API key.

The Render MCP server lets agents inspect services, databases, logs, and metrics through the official provider-hosted endpoint.

## Configuring Render Access

Before creating the connection, create or choose a Render API key.

Render API keys can grant broad access across Render workspaces and services. Review the key permissions and only connect keys that are appropriate for agent workflows.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Render**, then select **API key**.

Enter:

| Field   | Value          |
| ------- | -------------- |
| API key | Render API key |

## Official References

* [Render MCP server](https://render.com/docs/mcp-server)
* [Render hosted MCP changelog](https://render.com/changelog/connect-to-the-official-render-mcp-server-over-http)

This integration uses the hosted MCP server at `https://mcp.render.com/mcp`.


# Resend
Source: https://docs.mistle.dev/guides/resend-integration-setup

Connect Resend to Mistle

## Overview

Connect to Resend with a Resend API key.

The Resend integration exposes MCP access for email, contacts, broadcasts, domains, and webhooks.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Resend**, then select **API key**.

Enter:

| Field   | Value                                                                                            |
| ------- | ------------------------------------------------------------------------------------------------ |
| API key | Resend API key. Prefer a sending access key unless agents should manage the wider Resend account |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use Resend.
2. Add Resend to the profile's integration configuration.
3. Select the Resend MCP tool.
4. Save and publish the profile version.


# Sandbox Profiles
Source: https://docs.mistle.dev/guides/sandbox-profiles

Configure the tools, setup, and environment agents start with

## Overview

Sandbox profiles define the execution environment an agent starts with.

Use a sandbox profile to control:

* the agent runtime, such as Codex or OpenCode
* the sandbox runtime, such as Docker or E2B
* installed tools and runtimes
* setup scripts
* allowed integrations and connection behavior
* repository access through a Git connection
* environment configuration required for agent work

Profiles make agent environments repeatable. Instead of configuring every session by hand, teams publish profile versions and start sessions from those published versions.

## Draft And Published Versions

Sandbox profile changes are made as drafts. Publishing a profile version makes that configuration available for new sessions.

Published versions are immutable from the point of view of future sessions. To change the environment, edit the draft and publish a new version.

## Publish A Working Profile

A usable profile usually needs more than a name and base image. Before publishing, configure the pieces the agent will need at runtime:

1. Create or edit a sandbox profile draft.
2. Choose the agent runtime.
3. Choose the sandbox runtime and credentials.
4. Select the model provider, Git connection, and connector integrations the profile should expose to sessions.
5. Add repository or workspace configuration when the agent should work in source code.
6. Write and test the setup script.
7. Publish the profile version.
8. Wait for the snapshot to become ready.
9. Start a session from the published profile.

<Frame>
  <img alt="Sandbox profile draft editor showing runtime, Git connection, model provider, connector integrations, and tools" />
</Frame>

If the snapshot fails or stays unavailable, sessions cannot start from that published profile version until the snapshot is fixed or refreshed.

## Runtime And Connections

The **Runtime** section controls what kind of agent starts and where it runs:

* **Agent** chooses the agent runtime. Codex profiles use OpenAI-compatible model provider connections. OpenCode profiles can use OpenCode-compatible provider connections such as Anthropic and OpenCode Go.
* **Sandbox Runtime** chooses where the sandbox runs. Docker is used for local or self-hosted Docker deployments. E2B can be selected when the deployment and integration target expose it.
* **Credentials** controls whether the sandbox runtime uses Mistle-managed credentials or a workspace API key connection, when that provider supports both.
* **Git Connection** controls which Git provider connection supplies repositories and repository tools.

Model provider connections, Git connection, and connector integrations are saved on the draft profile version. Publishing the profile version makes those choices available to new sessions and triggers.

## Setup Scripts

Setup scripts are custom preparation steps that run during snapshot creation. They make the profile's starting environment explicit and repeatable, instead of leaving future sessions to depend on manual setup or agent-discovered setup work.

```text theme={null}
Base image
  ↓
Mistle prepares the profile-defined environment
  - agent runtime and configuration
  - repositories
  - integration-related MCP tools and configuration
  ↓
Setup script runs
  ↓
Snapshot captured
```

Mistle first prepares the profile-defined environment from the sandbox profile. The setup script then runs on top of that environment before the snapshot is captured.

Keep setup scripts deterministic and explicit. A session should not depend on manual setup that is not captured in the profile.

## Use Setup Assistant

Setup Assistant opens an agent workspace beside the setup script editor so you can ask an agent to build or fix the draft setup script for the current profile.

The assistant sandbox automatically has Mistle MCP enabled for the selected draft profile version. That lets the assistant read the profile context, update the draft setup script, and start setup-script test runs from inside its workspace.

To use Setup Assistant:

1. Open a sandbox profile draft.
2. Make sure the profile includes a model provider connection for the selected agent runtime.
3. Select **Setup Assistant** from the setup script controls.
4. Tell the assistant what the setup script needs to accomplish.
5. Let the assistant write the script, run setup-script tests, and update the draft setup script.
6. Review the updated setup script and test output before publishing the profile version.

<Frame>
  <img alt="Sandbox profile setup script editor with the Setup Assistant panel open" />
</Frame>

Setup Assistant is only available while editing a draft profile version, and it requires a model provider connection for the selected agent runtime. The assistant sandbox starts from the base image so the saved script does not depend on state created only inside the assistant session.

## Experiment With Setup Scripts

Setup script changes are made on draft profile versions. Published versions are read-only.

To experiment with a setup script:

1. Open the sandbox profile.
2. Edit the draft version.
3. Update the **Setup script** field.
4. Use **Setup script behavior** to confirm where repositories are cloned and which tools are available.
5. Select **Test setup script** to run the script in a temporary sandbox.
6. Inspect the test output, adjust the script, and test again.
7. Publish the profile version when the script is reliable.

<Frame>
  <img alt="Sandbox profile setup script editor with setup script behavior, Test control, and setup test output" />
</Frame>

Setup script testing is only available while editing a draft, and only after the script has content.

## Snapshots

When a profile version is published, Mistle can prepare a snapshot for that version. The snapshot captures the prepared environment so new sessions can start from the profile-specific image instead of rebuilding from the shared base image every time.

Read [Snapshots](/guides/snapshots) for the snapshot lifecycle.

## Triggers On A Profile

Open the **Triggers** tab on a sandbox profile to see triggers that use that profile. From there you can create a new trigger preselected for the profile, or select an existing event or scheduled trigger to edit it without leaving the profile.

<Frame>
  <img alt="Sandbox profile Triggers tab showing profile-scoped trigger list and selected trigger editor" />
</Frame>

## Next Steps

* Read [Snapshots](/guides/snapshots) to understand prepared profile images.
* Read [Sessions](/guides/sessions) to see how users start work from a profile.
* Read [Self-Hosted Configuration](/guides/self-hosted-configuration) for deployment-level sandbox settings.


# Sentry
Source: https://docs.mistle.dev/guides/sentry-integration-setup

Connect Sentry to Mistle

## Overview

Connect to Sentry through Sentry hosted MCP OAuth and Sentry issue webhooks.

The Sentry integration exposes hosted MCP access for issues, traces, releases, and projects. Mistle can also receive Sentry issue webhook events as triggers.

## Connect Sentry MCP

Open **Integrations** in the dashboard, choose **Sentry**, then select **Sentry MCP OAuth**.

The browser redirects to Sentry, the user approves access, and the returned OAuth credentials are stored for the connection.

There are no user-entered secret fields for this target.

## Connect Sentry Issue Webhooks

Use the **Sentry webhooks** connection method with a Sentry Internal Integration.

In Sentry:

1. Create an Internal Integration for the Sentry organization.
2. In **Internal Integration Details**, set **Webhook URL** to a temporary HTTPS endpoint that you control if Sentry requires a value before saving.
3. Leave issue webhooks disabled until the Mistle callback URL is installed.
4. Save the integration.
5. Copy the integration client secret.

In Mistle:

1. Open **Integrations** in the dashboard, choose **Sentry**, then select **Sentry webhooks**.
2. Paste the Sentry Internal Integration client secret.
3. Save the connection.
4. Copy the **Webhook callback URL** from the connection detail page.

Return to Sentry, replace the temporary URL with the Mistle **Webhook callback URL** in the Internal Integration **Webhook URL** field, then enable issue webhooks for the integration.

Mistle supports these Sentry issue webhook trigger events:

* `sentry.issue.created`
* `sentry.issue.resolved`
* `sentry.issue.assigned`
* `sentry.issue.archived`
* `sentry.issue.unresolved`

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use Sentry.
2. Add Sentry to the profile's integration configuration.
3. Select the Sentry MCP tool.
4. Save and publish the profile version.


# Sessions
Source: https://docs.mistle.dev/guides/sessions

Start interactive agent work in a configured sandbox

## Overview

Sessions are interactive agent workspaces started from a sandbox profile.

Use sessions for work such as:

* debugging failing tests
* reviewing code changes
* implementing repository changes
* investigating logs or provider state through integrations
* preparing pull requests

Each session runs in a sandbox environment with the tools, setup, and integration access defined by the selected sandbox profile and organization configuration.

## How Sessions Start

When a user starts a session, Mistle selects the requested sandbox profile version and creates a sandbox for the agent.

If the profile version has a usable snapshot, the sandbox can start from that prepared image. This avoids repeating setup work that was already captured by the profile snapshot.

When a repository is selected at session start, Mistle uses it as the agent's startup working directory. That working directory determines which repo-local instructions and skills the agent sees when the session begins.

## Start A Session

To start interactive agent work:

1. Open **Sessions**.
2. Create a new session.
3. Choose the sandbox profile for the work.
4. Choose the repository or workspace where the agent should start.
5. Describe the task for the agent.
6. Start the session.

<Frame>
  <img alt="New session page with sandbox profile, repository selection, and Start session action" />
</Frame>

If the profile is not available for new sessions, check that the profile has a published version and a ready snapshot.

## Use A Session

After a session starts, the session workbench becomes the main place where you collaborate with the agent, inspect the sandbox, and review changes before the work leaves Mistle.

<Frame>
  <img alt="Session workbench with chat, primary repository selection, current changes, TUI, terminal, and process controls" />
</Frame>

The header controls expose the active sandbox and repository state:

| Control            | Use it to                                                                              |
| ------------------ | -------------------------------------------------------------------------------------- |
| Status indicator   | See whether the sandbox is connected, stopped, or in an error state.                   |
| Primary repository | Choose which repository or workspace the chat, terminal, and changes panel should use. |
| **TUI**            | Switch the main panel from chat to the agent runtime's TUI inside the sandbox.         |
| Changes            | Open the current code changes for the selected repository.                             |
| Processes          | Open HTTP ports for loopback-listening processes running inside the sandbox.           |
| Terminal           | Open a shell workspace at the bottom of the session.                                   |

## Choose The Primary Repository

Profiles can expose one or more repositories or workspaces. Use the **Primary repository** selector to choose the working directory for the current turn.

The primary repository sets where new agent threads, the runtime TUI, terminals, repository status checks, and code diffs run. Set it to the repository where the agent should do the work.

This matters because repo-local instructions and skills are discovered from the working directory. Choosing the wrong repository can start the agent without the project-specific guidance it needs.

If a session does not have a repository, repository-dependent controls show an unavailable state instead of guessing which directory to use.

## Chat And TUI

The default session view is chat. Use it for normal agent instructions, follow-up questions, file attachments, approvals, and review comments.

Use **TUI** when you want to work directly in the selected agent runtime's native terminal interface. The TUI replaces the chat pane while it is open, and you can return to chat from the same header control.

When the active runtime exposes model options, the composer shows model and reasoning controls. Use them before sending a message when a task needs a different model or reasoning effort.

You can attach files from the composer by clicking the add-files control, pasting files, or dropping files into the composer. Attached files are sent with the next message.

## Review Code Changes

Open **Changes** to review the current repository diff without leaving the session.

The changes panel compares the selected repository with its default branch, shows tracked and untracked file changes, and keeps the review beside the conversation. Use this when you want to inspect the agent's work before asking for revisions, approving a file change, or preparing a pull request.

<Frame>
  <img alt="Session workbench showing current code changes beside the session conversation" />
</Frame>

You can leave line-level comments on the diff. Pending diff comments are attached to the composer so the next message can refer to exact files and lines.

## Run Terminal Commands

Open **Terminal** to run shell commands in the session sandbox. The terminal opens as a resizable bottom workspace and can contain multiple terminal tabs.

Use the terminal for direct checks such as package-manager commands, local scripts, repository inspection, or quick probes that do not need to go through the agent.

## Open Running Ports

When a process inside the sandbox listens on loopback, open **Processes** to expose the HTTP port in a new browser tab.

This is useful for previewing development servers, docs sites, Storybook, API explorers, or other local web tools started by the agent or by a terminal command.

<Frame>
  <img alt="Session workbench process popover listing running localhost ports that can be opened in a browser" />
</Frame>

Ports are available only while the sandbox is running and Mistle can connect to the session.

## Agent Access

Agents can use configured integrations to interact with external systems. Credentials are managed by Mistle and are not placed directly inside the sandbox as long-lived secrets.

The exact runtime, tools, model providers, and external-system access available in a session come from the profile, organization settings, and connected integrations.

## External Activity Links

When an agent writes back to supported external systems, Mistle adds a link back to the session where the work happened.

For example, Slack messages, GitHub comments or pull requests, Jira issues or comments, and Linear issues or comments can include a **View session** link. That link lets teammates open the Mistle session behind the external update and inspect the work context.

## Disk State

Sessions are workspaces for ongoing agent work. Sandboxes retain their disk state across ordinary stop/start cycles.

Use [Snapshots](/guides/snapshots) when a workflow needs a reusable prepared environment for many future sessions.

## Next Steps

* Read [Sandbox Profiles](/guides/sandbox-profiles) to configure the environment sessions start from.
* Read [Integrations](/guides/integrations) to connect external systems.
* Read [Triggers](/guides/triggers) for event-triggered agent sessions.


# SigNoz
Source: https://docs.mistle.dev/guides/signoz-integration-setup

Connect SigNoz to Mistle

## Overview

Connect to SigNoz through a SigNoz OAuth flow. The connection also needs the SigNoz Cloud region so the hosted MCP issuer URL can be built correctly.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **SigNoz**, then select **SigNoz OAuth**.

When prompted, enter:

| Field  | Value                                                                                                                     |
| ------ | ------------------------------------------------------------------------------------------------------------------------- |
| Region | SigNoz Cloud region. Open **Settings > Ingestion** in SigNoz: `us` and `us2` endpoints use `us`; `eu` endpoints use `eu`. |

That region is used to build the hosted issuer and MCP URLs:

* Issuer: `https://mcp.<region>.signoz.cloud`
* MCP: `https://mcp.<region>.signoz.cloud/mcp`

After that, the user completes the OAuth redirect flow in SigNoz.

## Official References

* [SigNoz MCP Server](https://signoz.io/docs/signoz-mcp-server/)

The region-specific hosted MCP and OAuth behavior above is inferred from the current SigNoz integration implementation. SigNoz's public docs currently document the MCP server more directly than this hosted OAuth flow.


# Slack
Source: https://docs.mistle.dev/guides/slack-integration-setup

Connect Slack to Mistle

## Overview

Slack can be connected in two ways:

1. **Slack app**
   * **Create from manifest** (recommended): Mistle creates and configures the Slack app via a manifest
   * **Use an existing app**: connect a Slack app you already created in Slack
2. **Bot token**
   * Use this when the connection only needs Slack app credentials and you do not want Mistle to create the app from a manifest

## Option 1: Connect With A Slack App

Set up a Slack app, configure the required bot scopes and event subscriptions, install it to your workspace, then connect it to Mistle with the bot token and signing secret.

Choose one of these setup paths:

1. **Create from manifest** (recommended): Mistle creates and configures the Slack app via a manifest.
2. **Use an existing app**: connect a Slack app you already created in Slack.

### Option 1A: Create From Manifest (Recommended)

1. Open **Integrations** in the dashboard and choose **Slack**.
2. Select **Slack app**.
3. Choose **Create from manifest**.
4. Generate a Slack app configuration token in Slack and paste it into Mistle.
5. Review and edit the manifest before creating the app.
6. Submit the manifest to Slack.
7. Approve the Slack app installation in your workspace.
8. Return to Mistle to complete the connection.

<Frame>
  <img alt="Mistle Slack App setup page with Create from manifest selected, token input, and editable Slack app manifest" />
</Frame>

You can edit the manifest before creating the app. Mistle will use your manifest values for app settings such as the app name, description, and other Slack app configuration that does not need to be managed by Mistle.

To keep the integration working, Mistle always overrides the Slack app webhook and callback settings before submitting the manifest. Mistle sets the Events API request URL to the Mistle callback URL for that connection, adds the required redirect URLs for Slack app installation and Slack identity linking, and adds the required bot scopes and bot events needed for supported Slack triggers and resource sync.

### Option 1B: Use An Existing Slack App

If you already created a Slack app, you can connect it directly in Mistle.

### Configure Bot Scopes

Add these bot scopes before installing the app:

| Scope               | Enables                                               |
| ------------------- | ----------------------------------------------------- |
| `app_mentions:read` | Receive `app_mention` events for Slack triggers       |
| `channels:history`  | Receive public channel messages for Slack triggers    |
| `channels:read`     | Sync public channels as selectable trigger resources  |
| `files:read`        | Read and download files shared with the app           |
| `files:write`       | Upload files as the app                               |
| `groups:history`    | Receive private channel messages for Slack triggers   |
| `groups:read`       | Sync private channels as selectable trigger resources |
| `usergroups:read`   | Sync user groups as selectable trigger resources      |
| `users:read`        | Sync users as selectable trigger resources            |

### Configure Event Subscriptions

Enable the Slack Events API and subscribe the bot to these events:

| Event               | Enables                                       |
| ------------------- | --------------------------------------------- |
| `app_mention`       | Slack trigger source                          |
| `channel_created`   | Refresh synced public channels when created   |
| `channel_archive`   | Refresh synced public channels when archived  |
| `channel_unarchive` | Refresh synced public channels when restored  |
| `channel_rename`    | Refresh synced public channels when renamed   |
| `group_archive`     | Refresh synced private channels when archived |
| `group_unarchive`   | Refresh synced private channels when restored |
| `group_rename`      | Refresh synced private channels when renamed  |
| `message.channels`  | Slack message triggers in public channels     |
| `message.groups`    | Slack message triggers in private channels    |
| `subteam_created`   | Refresh synced user groups when created       |
| `subteam_updated`   | Refresh synced user groups when updated       |
| `team_join`         | Refresh synced users when a member joins      |
| `user_change`       | Refresh synced users when member data changes |

### Install The App And Collect Credentials

Install the Slack app to the workspace, then collect:

1. The bot token (`xoxb-...`)
2. The signing secret from the app's Basic Information page

### Connect The Existing App In Mistle

Open **Integrations** in the dashboard, choose **Slack**, then select **Slack app**.

Enter:

| Field                            | Value                   |
| -------------------------------- | ----------------------- |
| Bot token                        | Slack bot token         |
| Signing secret                   | Slack signing secret    |
| Client ID (Linked User Auth)     | Slack app client ID     |
| Client secret (Linked User Auth) | Slack app client secret |

The linked-user auth fields are required when this connection will be used for Identity Linking. Standard Slack bot usage does not require them.

### Webhooks

If you use Slack triggers:

1. Open the connection's **Webhooks** section in Mistle.
2. Copy the displayed callback URL.
3. Paste it into the Slack app's **Events API Request URL** field.
4. Save and verify the request URL in Slack.

<Frame>
  <img alt="Slack app connection detail page showing authentication, synced channel resources, and webhook callback URL" />
</Frame>

## Private Channels

If you want Mistle to sync or trigger from private channels, invite the Slack app to each private channel you want to use.

Slack only delivers private-channel messages and events to apps that are members of that channel. If the app is not a member, Mistle cannot see activity in the channel, sync it as a selectable resource, or respond to `app_mention` events there.

## Official References

* [Slack app manifest](https://docs.slack.dev/reference/app-manifest/)
* [Creating an app from app settings](https://docs.slack.dev/app-management/quickstart-app-settings)
* [Using HTTP Request URLs](https://docs.slack.dev/apis/events-api/using-http-request-urls/)
* [app\_mention event](https://docs.slack.dev/reference/events/app_mention/)
* [team\_join event](https://docs.slack.dev/reference/events/team_join)
* [user\_change event](https://docs.slack.dev/reference/events/user_change)
* [subteam\_created event](https://docs.slack.dev/reference/events/subteam_created)
* [subteam\_updated event](https://docs.slack.dev/reference/events/subteam_updated)
* [conversations.list](https://docs.slack.dev/reference/methods/conversations.list/)
* [users.list](https://docs.slack.dev/reference/methods/users.list/)
* [usergroups.list](https://docs.slack.dev/reference/methods/usergroups.list/)


# Snapshots
Source: https://docs.mistle.dev/guides/snapshots

Start sessions from prepared sandbox profile images

## Overview

Snapshots are prepared sandbox images for published sandbox profile versions.

They make new sessions start from a profile-specific image instead of rebuilding everything from the shared base image every time. A snapshot captures the result of applying a published profile version's runtime plan and setup script to a one-off sandbox, then stores the resulting provider image handle on that profile version.

## What Snapshots Are For

Snapshots make sandbox startup faster and more predictable.

They are useful when a sandbox profile needs repeatable setup before users start sessions, such as:

* installing language runtimes or CLI tools
* preparing agent configuration
* applying setup scripts
* baking common dependencies into the launch image

Once a snapshot is ready, new sessions for that published profile version launch from the snapshot image.

## Lifecycle

Snapshots are tied to sandbox profile versions.

* Publishing a draft version queues the initial snapshot job.
* Manual refresh queues a new snapshot job for an already published version.
* Scheduled refresh can queue snapshot jobs for profiles that need regular rebuilds.
* A profile version is not usable for new sessions until its published version has a usable snapshot image.
* Failed refreshes keep the existing usable snapshot when one already exists.

Only one queued or running snapshot job is allowed per profile version at a time.

## Check Snapshot Status

Snapshot status is shown on the sandbox profile version. Use it when a profile is not available for new sessions.

Common states to look for:

* queued or running: Mistle is still preparing the snapshot
* ready: new sessions can start from the prepared image
* failed: inspect the setup script and snapshot output, then refresh the snapshot after fixing the profile

<Frame>
  <img alt="Published sandbox profile snapshot panel showing a ready snapshot and refresh schedule" />
</Frame>

If setup changes are needed, edit the draft profile version, test the setup script, and publish a new version.

## What Snapshots Are Not

Snapshots are not per-session durable storage. They do not preserve the ongoing filesystem changes from a user's sandbox session.

Use snapshots when many future sandboxes should start from the same prepared image.

## Next Steps

* Read [Sandbox Profiles](/guides/sandbox-profiles) for the profile lifecycle.
* Read [Sessions](/guides/sessions) for how users start agent work from a prepared profile.


# Stripe
Source: https://docs.mistle.dev/guides/stripe-integration-setup

Connect Stripe to Mistle

## Overview

Connect to Stripe through Stripe hosted MCP OAuth.

The Stripe integration exposes hosted MCP access for customers, invoices, products, payments, and documentation.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Stripe**, then select **Stripe MCP OAuth**.

The browser redirects to Stripe, the user approves access, and the returned OAuth credentials are stored for the connection.

There are no user-entered secret fields for this target.

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use Stripe.
2. Add Stripe to the profile's integration configuration.
3. Select the Stripe MCP tool.
4. Save and publish the profile version.


# Supabase
Source: https://docs.mistle.dev/guides/supabase-integration-setup

Connect Supabase to Mistle

## Overview

Connect to Supabase through Supabase hosted MCP OAuth.

The Supabase integration exposes hosted MCP access for projects, databases, Auth, Edge Functions, environment configuration, analytics, and secrets.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Supabase**, then select **Supabase MCP OAuth**.

The browser redirects to Supabase, the user approves access, and the returned OAuth credentials are stored for the connection.

There are no user-entered secret fields for this target.

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use Supabase.
2. Add Supabase to the profile's integration configuration.
3. Select the Supabase MCP tool.
4. Save and publish the profile version.

## Access Scope

This integration requests Supabase hosted MCP OAuth scopes for reading organizations, projects, databases, analytics, secrets, Edge Functions, and environment configuration, plus write access for projects, databases, Edge Functions, and environment configuration.

Review agent tool calls before approving changes that modify Supabase projects, database schema, Edge Functions, or environment configuration.

## Official References

* [Supabase MCP Server](https://supabase.com/docs/guides/ai-tools/mcp)
* [Announcing the Supabase Remote MCP Server](https://supabase.com/blog/remote-mcp-server)

This integration uses the hosted MCP server at `https://mcp.supabase.com/mcp`.


# Telegram
Source: https://docs.mistle.dev/guides/telegram-integration-setup

Connect Telegram to Mistle

## Overview

Connect Telegram to Mistle with a Telegram bot token from BotFather.

The Telegram integration exposes Telegram Bot API operations through the Telegram CLI and Telegram MCP tools. Mistle stores the bot token on the connection and injects it into managed egress requests outside the sandbox.

## Create A Telegram Bot

1. Open [BotFather](https://t.me/BotFather) in Telegram.
2. Create a bot with `/newbot`, then follow the prompts for the bot name and username.
3. Copy the bot token returned by BotFather.

For an existing bot, use BotFather's token management commands to retrieve or rotate the token.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Telegram**, then select **Telegram bot**.

Enter:

| Field     | Value                             |
| --------- | --------------------------------- |
| Bot token | Telegram bot token from BotFather |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use Telegram.
2. Add Telegram to the profile's integration configuration.
3. Select the Telegram CLI, Telegram MCP, or both.
4. Save and publish the profile version.

## Chats, Groups, Channels, And Topics

Telegram decides which chats, groups, channels, and forum topics a bot can access. Add the bot to each Telegram space where it should operate and grant the Telegram-side permissions needed for the operations your agents will run.

Forum topic operations require a forum-enabled group and Telegram permissions that allow the bot to manage topics. Message operations can target a topic by passing the Telegram `message_thread_id`.

## Official References

* [BotFather](https://t.me/BotFather)
* [Telegram Bot API](https://core.telegram.org/bots/api)
* [Telegram bot tutorial](https://core.telegram.org/bots/tutorial)
* [sendMessage](https://core.telegram.org/bots/api#sendmessage)
* [editMessageText](https://core.telegram.org/bots/api#editmessagetext)
* [deleteMessage](https://core.telegram.org/bots/api#deletemessage)
* [setMessageReaction](https://core.telegram.org/bots/api#setmessagereaction)
* [createForumTopic](https://core.telegram.org/bots/api#createforumtopic)


# Tensorlake
Source: https://docs.mistle.dev/guides/tensorlake-integration-setup

Connect Tensorlake sandbox runtime access to Mistle

## Overview

Tensorlake provides a sandbox runtime for running Mistle sandboxes with an organization-owned Tensorlake API key.

Use this connection when a sandbox profile should use workspace-owned Tensorlake credentials.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Tensorlake**, then select **API key**.

Enter:

| Field   | Value              |
| ------- | ------------------ |
| API key | Tensorlake API key |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should run on Tensorlake.
2. Choose **Tensorlake** as the sandbox runtime.
3. Select the Tensorlake credentials connection.
4. Save and publish the profile version.

For self-hosted deployments, the Tensorlake runtime must also be enabled in deployment configuration before profiles can use it.


# Triggers
Source: https://docs.mistle.dev/guides/triggers

Trigger agent work from external events

## Overview

Triggers start agent work in response to external events, such as webhook deliveries from connected systems, or from a saved schedule.

Use triggers when a team wants Mistle to react to provider activity or time-based schedules without a user manually starting every session.

Examples include:

* responding to Slack app mentions
* reacting to GitHub events
* starting triage or follow-up work from integration webhooks

## Requirements

Triggers depend on the same building blocks as interactive sessions:

* a sandbox profile that defines the agent environment
* integrations that connect the external systems involved
* webhook or callback configuration for providers that send events to Mistle
* account linking when provider activity should be attributed to a specific Mistle user

## Trigger Types

Mistle supports two trigger shapes:

* Event triggers respond to provider events, such as Slack app mentions or GitHub webhooks.
* Scheduled triggers run on a saved schedule and start work without waiting for a provider event.

Both shapes use a sandbox profile to define the environment where agent work runs.

## Create A Trigger

To create a trigger:

1. Open **Triggers**.
2. Create a new trigger.
3. Choose the sandbox profile that should run the work.
4. Choose whether it should be event-triggered or scheduled.
5. Select the integration event or schedule.
6. Choose the primary repository when the selected profile provides repository options.
7. Describe the task or instructions the agent should follow.
8. Save the trigger.

### Event Triggers

Event triggers listen for a provider event, such as a Slack app mention, then start agent work with the selected sandbox profile and repository context.

<Frame>
  <img alt="Event trigger form with Slack app mention source, sandbox profile, repository, and instructions" />
</Frame>

For event triggers, make sure the provider integration has webhook delivery configured and can reach Mistle.

### Scheduled Triggers

Scheduled triggers run from a saved schedule. The schedule, timezone, sandbox profile, repository, and instructions define what work Mistle starts each time the schedule fires.

<Frame>
  <img alt="Scheduled trigger form with cron schedule, timezone, sandbox profile, repository, and saved instructions" />
</Frame>

## Primary Repository

For triggers, the primary repository is saved with the trigger target. Each run uses it as the agent's startup working directory, so event-triggered and scheduled work begins in the intended repository without a user choosing it at runtime.

Set the primary repository to the repo where the trigger should read instructions, discover skills, run commands, and collect code changes. If it is left unset, the trigger can still start from the selected sandbox profile, but repository-specific behavior depends on the profile's default workspace rather than an explicit repository choice.

## Manage Triggers From A Profile

Each sandbox profile has a **Triggers** tab that lists event and scheduled triggers using that profile. Use it when you want to review profile-specific trigger behavior, edit a trigger in place, or create a new trigger already scoped to that profile.

<Frame>
  <img alt="Sandbox profile Triggers tab with a list of triggers and an inline trigger editor" />
</Frame>

## Event Flow

A typical trigger flow is:

1. A provider sends an event to Mistle.
2. Mistle validates the event and resolves the relevant organization, integration, resource, and requester context.
3. Mistle starts agent work using the configured sandbox profile.
4. The agent uses configured integrations to complete the task and report back through the appropriate system.

When triggered work writes back to supported external systems, those updates can include a [session link](/guides/sessions#external-activity-links) so teammates can open the Mistle session behind the update.

## Attribution

When a trigger is started by a provider user, Mistle can use account linking to resolve that provider identity back to a Mistle user.

Read [Account Linking](/guides/account-linking) for identity attribution across providers.

## Next Steps

* Read [Integrations](/guides/integrations) for the provider connection model.
* Read [Account Linking](/guides/account-linking) for requester attribution.
* Read [Sandbox Profiles](/guides/sandbox-profiles) and [Sessions](/guides/sessions) for the execution environment used by trigger runs.
* For self-hosted deployments, read [Webhook And Callback URLs](/guides/self-hosted-webhook-callbacks).


# Whapi
Source: https://docs.mistle.dev/guides/whapi-integration-setup

Connect Whapi to Mistle

## Overview

Connect to Whapi with a Whapi API token.

The Whapi integration exposes MCP tools for Whapi's WhatsApp API and webhook triggers for Whapi channel callbacks.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Whapi**, then select **API token**.

Enter:

| Field          | Value                                                                                   |
| -------------- | --------------------------------------------------------------------------------------- |
| API token      | Whapi API token                                                                         |
| Webhook secret | Shared secret to configure as the Whapi custom callback header `x-whapi-webhook-secret` |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use Whapi.
2. Add Whapi to the profile's integration configuration.
3. Select the Whapi MCP tool.
4. Save and publish the profile version.

## Webhook Setup

Create a Whapi webhook in Body mode and point it at the callback URL shown in Mistle.

Configure Whapi custom callback headers with:

| Header                   | Value                                              |
| ------------------------ | -------------------------------------------------- |
| `x-whapi-webhook-secret` | The webhook secret stored on the Mistle connection |

Whapi message callbacks use events such as `messages.post` and `messages.put`. Status callbacks use events such as `statuses.post` and `statuses.put`. Account and device status callbacks use `channel.post`, and user connection callbacks use `users.post` or `users.delete`.

## Official References

* [Whapi webhook events](https://support.whapi.cloud/help-desk/receiving/webhooks/our-webhooks-tracked-events)
* [Whapi webhook format](https://support.whapi.cloud/help-desk/receiving/webhooks/incoming-webhooks-format)
* [Whapi custom callback headers](https://support.whapi.cloud/help-desk/account/customizable-webhook-headers)
* [Whapi MCP package](https://github.com/Whapi-Cloud/whapi-mcp)


# Xero
Source: https://docs.mistle.dev/guides/xero-integration-setup

Connect Xero to Mistle

## Overview

Xero connects to Mistle with OAuth 2.0 authorization code flow.

After authorization, Mistle exposes Xero through the Xero MCP tools in sandbox profiles. The tools can list connected tenants and make authenticated requests to the Xero Accounting, Files, Assets, and Projects API families.

## Prerequisites

* A Xero account with access to the organization you want to connect
* A Xero OAuth 2.0 app in the [Xero Developer portal](https://developer.xero.com/)
* The Mistle OAuth callback URL shown during connection setup
* A Xero client ID and client secret

## Configure Xero

Create or open your OAuth 2.0 app in the Xero Developer portal, then add the Mistle callback URL as an allowed redirect URI.

Xero does not support wildcard redirect URIs. Use the exact callback URL shown in Mistle.

## Connect in Mistle

In Mistle, choose **Xero**, then connect with:

| Field         | Value                      |
| ------------- | -------------------------- |
| Client ID     | Xero OAuth client ID       |
| Client secret | Xero OAuth client secret   |
| Scopes        | Xero OAuth scopes to grant |

Mistle defaults to the minimum scope needed to keep the connection refreshable:

* `offline_access`

Xero requires `offline_access` when the connection should receive a refresh token and stay connected after the short-lived access token expires.

Add the specific Xero API scopes needed for the endpoints your agents will use. Xero apps created on or after March 2, 2026 use granular scopes, so use the current granular scopes from Xero's developer documentation instead of broad legacy scopes such as `accounting.transactions`.

## Use Xero MCP

After the connection is authorized, bind Xero to a sandbox profile. Sessions using that profile can call:

* `xero_tenants_list`
* `xero_api_get`
* `xero_api_post`
* `xero_api_put`
* `xero_api_delete`

Call `xero_tenants_list` first to find the `tenantId` for the Xero organization. API calls then require:

| Field      | Value                                                                       |
| ---------- | --------------------------------------------------------------------------- |
| `family`   | `accounting`, `files`, `assets`, or `projects`                              |
| `tenantId` | Xero tenant ID returned by `xero_tenants_list`                              |
| `endpoint` | Xero endpoint path, such as `/Invoices`, `/Contacts`, or `/Files`           |
| `body`     | JSON request body for `POST` and `PUT` requests, when the endpoint needs it |

## Current Limitations

Xero webhooks are not configured by the Mistle Xero integration yet.

## Official References

* [Xero OAuth 2.0 authorization code flow](https://developer.xero.com/documentation/guides/oauth2/auth-flow/)
* [Xero OAuth 2.0 scopes](https://developer.xero.com/documentation/guides/oauth2/scopes/)
* [Xero granular scopes FAQ](https://developer.xero.com/faq/granular-scopes)
* [Xero tenants](https://developer.xero.com/documentation/guides/oauth2/tenants)


# Z.ai
Source: https://docs.mistle.dev/guides/zai-integration-setup

Connect Z.ai model access to Mistle

## Overview

Z.ai provides model access for sandbox profiles that use OpenCode-compatible agent runtimes.

Use this connection when a profile should call Z.ai models through an API key managed by Mistle.

## Connect In Mistle

Open **Integrations** in the dashboard, choose **Z.ai**, then select **API key**.

Enter:

| Field   | Value        |
| ------- | ------------ |
| API key | Z.ai API key |

## Use With A Sandbox Profile

After the connection exists:

1. Open the sandbox profile that should use Z.ai.
2. Add Z.ai as a model provider connection.
3. Save and publish the profile version.


# Introduction
Source: https://docs.mistle.dev/index

Learn how to use Mistle to connect integrations, configure sandbox profiles, launch coding-agent sessions, and automate work with triggers.

## What Mistle Provides

* [Integrations](/guides/integrations) connect external systems and models such as GitHub, Slack, OpenAI, Anthropic, OpenCode Go, Datadog, Jira, and Linear.
* [Account linking](/guides/account-linking) maps provider identities back to Mistle users so work can be attributed to the right person.
* [Sandbox profiles](/guides/sandbox-profiles) define the tools, permissions, setup, and environment an agent starts with.
* [Snapshots](/guides/snapshots) capture prepared sandbox environments so sessions can start quickly with required tools and dependencies already available.
* [Sessions](/guides/sessions) start interactive agent work such as debugging, code review, and repository changes.
* [Triggers](/guides/triggers) respond to external events and run saved schedules.

## Start Here

* Visit [Quickstart](/quickstart) to create your first sandbox instance.
* Read [Sandbox Profiles](/guides/sandbox-profiles) and [Sessions](/guides/sessions) to understand how agent work is configured and started.
* Use the provider pages in the `Integrations` section for specific details on how to connect to each provider.


# Quickstart
Source: https://docs.mistle.dev/quickstart

Create your first sandbox instance in Mistle.

## Overview

Use this guide to connect OpenAI and GitHub, publish a sandbox profile, wait for its snapshot, and start your first session.

## Prerequisites

* Access to a Mistle workspace
* An OpenAI API key or ChatGPT subscription
* A GitHub account with access to the repositories the agent should work in

## Connect OpenAI

Open **Integrations**, choose **OpenAI**, and create a connection.

For a simple first run, use **API key** and enter the OpenAI API key Mistle should use for model access.
If your workspace uses interactive ChatGPT access instead, choose **ChatGPT subscription** and complete the device-authorization flow.

Read [OpenAI](/guides/openai-integration-setup) for the full connection options.

## Connect GitHub

Open **Integrations**, choose **GitHub**, and create a connection.

For a simple first run, use **GitHub App installation** with **Create from manifest**. Mistle builds the GitHub App manifest, sends you to GitHub to create and install the app, then returns you to Mistle to complete the connection.

<Frame>
  <img alt="Mistle GitHub App setup page with Create from manifest selected and an editable GitHub App manifest" />
</Frame>

Read [GitHub](/guides/github-integration-setup) for existing-app setup, API-key setup, and GitHub Enterprise Server notes.

## Create A Sandbox Profile

Open **Sandbox Profiles** and create a new profile.

Configure the draft profile with:

* **Agent**: choose Codex for an OpenAI-backed first session.
* **Git Connection**: choose the GitHub connection you created.
* **Model provider**: choose the OpenAI connection you created.
* **Setup script**: add the setup commands the agent's sandbox should run before sessions start.

<Frame>
  <img alt="Sandbox profile draft editor showing runtime, Git connection, model provider, connector integrations, and tools" />
</Frame>

Save the draft when your profile settings are ready.

## Publish And Wait For The Snapshot

Select **Publish** on the draft profile version.

Publishing creates the published profile version and queues snapshot creation. New sessions can use that version after the snapshot is ready.

The snapshot prepares the sandbox image by applying the published runtime plan and setup script.

Wait until the snapshot status is ready before starting a session. If snapshot creation fails, inspect the snapshot output, update the draft profile, and publish a new version.

<Frame>
  <img alt="Published sandbox profile snapshot panel showing a ready snapshot and refresh schedule" />
</Frame>

Read [Snapshots](/guides/snapshots) for the snapshot lifecycle.

## Start A Session

Open **Sessions**, create a new session, and select:

* **Sandbox profile**: the profile you just published.
* **Primary repository**: the GitHub repository where the agent should start.

Select **Start session**. Mistle starts a sandbox instance from the published profile snapshot and opens the session workbench.

<Frame>
  <img alt="New session page with sandbox profile, repository selection, and Start session action" />
</Frame>

After the workbench opens, send the agent a small first task so you can confirm the profile, repository, and model connection are working together.

## Next steps

* Read [Sandbox Profiles](/guides/sandbox-profiles) to understand how sandbox environments are configured.
* Read [Sessions](/guides/sessions) to learn how to use the session workbench.
* Add connector integrations when the agent needs access to Slack, Jira, Linear, Datadog, or other external systems.