Integrations

Your Teammates can work inside the tools your business already runs on — CRMs, calendars, project trackers, support desks, and 1,000+ other tools. Each connection belongs to one specific Teammate: connecting your CRM to your sales Teammate doesn't expose it to any other Teammate on the server.

The easiest way: just ask

The fastest way to connect a tool is to ask the Teammate that needs it:

"Connect my HubSpot account."

Your Teammate will set up the connection and walk you through any sign-in step the tool requires. Every Teammate knows how to do this out of the box — there's nothing to install or enable first.

Note: A Teammate can only ever act through connections that have been authorized for it. Asking one Teammate to connect an account never grants access to the others.

From the dashboard

Each Teammate's Tools page has an Agent integrations section where you can see and manage everything that Teammate is connected to:

• Browse and connect — pick a tool from the catalog and complete its sign-in. Most tools use the provider's own sign-in page; some ask for an API key instead.
• Reconnect — if a connection expires or a tool revokes access, reconnect it in place. The Teammate picks the connection back up without any other changes.
• Disconnect — removes the Teammate's access. The Teammate stops using that integration until it's reconnected.

Note: Integration connections are the one thing on the platform that doesn't wait for a deploy. Everything else stages as a pending change; a connection is live for the Teammate as soon as the sign-in completes — and gone as soon as you disconnect it.

Integrations vs. custom APIs

The integrations catalog covers tools with managed sign-ins. For anything else — an internal service, a niche API — your Teammates can still call any HTTP API directly. For those, you provide the credential yourself as a secret with a host allowlist, and the platform keeps the raw key out of the Teammate's reach.

If a custom API call starts returning authentication errors, that's usually a host-allowlist issue — see Troubleshooting.

GitHub

Connecting a GitHub App to a Teammate is one of the dashboard-only flows mentioned above — open the Teammate's Tools page, click Connect GitHub, and finish the setup GitHub walks you through. No separate webhook needs setting up per repository: once the App is installed, GitHub starts delivering pull request, review, and comment events to that Teammate on its own. Unlike the catalog connections above, that delivery is a configuration change like any other — it goes live after your next deploy, not the moment you finish connecting.

The permissions GitHub asks you to approve depend on the Teammate's role. An Engineer Teammate gets write access to code, pull requests, and issues, so it can push commits and open PRs. A QA Teammate gets the reviewer profile described next, plus read access to commit statuses and Actions runs, which its pull request grading needs (see below). Every other role, including a custom Teammate, gets the reviewer profile: read access to your code, plus the ability to review, approve, and comment on pull requests, enough to review work without being able to push changes. No profile can edit your repository's CI/workflow configuration.

A QA Teammate reviews each pull request with inline comments and a summary, and approves the pull request when its review comes back clean. It approves the exact commit it reviewed, and only when its own review found nothing open, the PR isn't a draft, no check has failed, the PR description carries a summary and test evidence (plus blast radius and rollback for infrastructure changes), and the PR doesn't touch .github/ or secret files. Anything short of that gets the usual comments and no approval, with the summary saying why, and the Teammate withdraws any approval it gave the PR earlier. It never requests changes. Approving uses the pull request write permission. Grading reads your CI results through commit statuses and check runs, looks up any Actions run the PR description cites, and reads whether your branch rules dismiss stale approvals. That check works with rulesets out of the box. If you use classic branch protection instead, either move the rule to a ruleset or give the App Administration: Read-only; otherwise the Teammate can't confirm stale approvals are dismissed and won't approve. If you point the grader's weekly report at a GitHub issue, also give the App Issues: Read and write, since the QA profile only reads issues. An approval from the Teammate's GitHub App only counts toward a required review if your branch rules accept it: a rule that requires a review from a specific team can't be satisfied by an App. Turn on your repository's "Dismiss stale pull request approvals when new commits are pushed" rule so an approval never carries over to commits the Teammate hasn't reviewed. With that rule on, each push clears the approval, and the Teammate only approves again if its pull request webhook also fires on new pushes. Each re-review is one more run on the Teammate's model, which counts toward your usage.

Updating an existing GitHub App's permissions

GitHub never changes the permissions of an App that's already installed. When a Teammate needs a permission its App was created without, the Teammate's Tools page shows a warning on the GitHub card listing what's missing. To add it:

1. On github.com, open the App's settings. For an App owned by an organization, go to the organization's Settings, then Developer settings, then GitHub Apps, and click Edit next to the App. For an App on your personal account, go to your own Settings, then Developer settings, then GitHub Apps, and click Edit next to the App. The warning on the Tools page links straight to this page.
2. Open Permissions & events. Under Repository permissions, set each permission the warning lists to the level it names, for example Commit statuses: Read-only. Click Save changes at the bottom of the page.
3. Accept the change on the installation. GitHub emails the installation's owner a review request, or you can go there directly. For an organization, go to its Settings, then Third-party Access, then GitHub Apps (https://github.com/organizations/<your-org>/settings/installations). For your personal account, go to Settings, then Integrations, then Applications, and open the Installed GitHub Apps tab (https://github.com/settings/installations). Click Configure next to the App, then Review request, then Accept new permissions. Until someone accepts, the App keeps its old permissions.
4. Reload the Teammate's Tools page. The warning clears once GitHub reports the new permissions on the installation. The Teammate may keep working with the old permissions for up to an hour, until its GitHub access token renews.

Engineering workflow settings

If your agent server has a QA Reviewer or Engineer Teammate, you can tune how they review and write code from the Engineering workflow tab on the agent server's page in the dashboard. The tab is shown on every agent server; an agent server with neither kind of Teammate shows an empty state with an Add Agent button instead of settings.

The page has a Shared section and one section per QA Reviewer or Engineer Teammate:

• Shared settings are entered once and applied to every QA Reviewer and Engineer Teammate on the agent server. If your Teammates currently disagree on a shared setting, the page says so, and saving applies the value shown to all of them.
• Each Teammate has its own settings, plus a status badge. A QA Reviewer shows Off, Saved, deploy to apply, or Active, and has an on/off switch. An Engineer shows Using defaults, Saved, deploy to apply, or Active, and has no switch.
• Number settings show their minimum and maximum, and choice settings list their options. A value the page can't accept is rejected with a message beside the field; nothing is saved until every field is valid.
• A box titled Always applied (not editable) on a QA Reviewer lists the protections you can't change, such as the paths whose changes are never auto-approved.
• Most list settings take one entry per line. Once you edit a list that replaces the built-in entries, new built-in entries we add later won't be included.
• Per-repository overrides (advanced) takes JSON keyed by owner/name, up to 50 repositories. Each entry holds that repository's setting overrides, and an entry can't contain its own repos or version, or any metrics setting; metrics settings apply to the whole QA Reviewer.
• A setting this version of the dashboard can't edit yet is shown read-only; its current value is kept when you save.

Click Save changes to stage your edits. Nothing changes on your Teammates until you deploy; the confirmation links to the Deploys page. Turning a QA Reviewer off and saving removes its settings file at the next deploy, and turning it on again and saving creates the file again.

QA-GRADER.md and DEV-WORKFLOW.md hold these settings and show read-only in the workspace editor. If someone edits one of those files outside this page, the page imports what it can, lists any settings it ignored or didn't accept, and shows the default for those. Saving then rewrites the file from the settings on screen.

Programmatically, the same settings are available through the REST API at GET and PUT /api/v1/instances/{instanceId}/engineering-workflow, and through the MCP tools get_engineering_workflow and save_engineering_workflow. Saving through either stages the same files, and nothing applies until you deploy. See API & MCP and Workspace & soul documents.

API and MCP

Managing integration connections isn't part of the HTTP API or MCP toolset yet — use the dashboard, or ask the Teammate to connect the account itself. See API & MCP for what's covered where.