Pre-built Integrations

Airlock includes 240+ pre-built integrations that let you connect AI agents to popular services without writing an OpenAPI spec. Most are MCP proxies that route tool calls to the service's own upstream MCP server; around twenty services that don't offer a suitable MCP server of their own — including several of the built-in OAuth integrations — are proxied through an airlock-hosted MCP server instead.

The categories below highlight commonly-used integrations. The complete, up-to-date list is what you see under Integrations in the Control Room.

Available Integrations

Code & Project Management

CRM & Sales

Customer Support

Marketing & Email

Meetings & Communication

Infrastructure & Deployment

Monitoring & Analytics

Payments

Documentation & Data

Websites & Content

Design & Media

AI & Machine Learning

Automation

HR & Recruiting

ERP

Forms & Email Validation

Airlock-hosted MCP Integrations

Some services don't expose their own MCP server (or expose one airlock can't proxy), so airlock hosts one for them. These are still MCP proxies — they forward tool calls to an airlock-hosted MCP server rather than a vendor-run one. This is an implementation detail: you connect them exactly like any other integration, with whatever auth type is listed for them above (built-in OAuth ones via Connect, API-key ones by entering a key on the integration's detail page).

The airlock-hosted integrations are:

• Built-in OAuth: Slack, Gmail, Google Calendar, Google Drive, Outlook, Outlook Calendar, OneDrive, Microsoft Teams, Bitbucket, Figma, Vercel, Dynamics 365 CRM
• API key / token: Aikido, Ashby, Atlassian Goals & Projects, Azure DevOps (token), BounceBan, CodeRabbit, Dagster+, Datadog, Freshdesk, Odoo, PhantomBuster, Process Street, Redmine, ZeroBounce
• Manual OAuth setup: Zoom

Authentication Types

Built-in OAuth

Integrations marked Built-in OAuth (GitHub, Bitbucket, Azure DevOps, Slack, Figma, Google Calendar, Gmail, Outlook, Outlook Calendar, Microsoft Teams, Google Drive, OneDrive, Vercel, Dynamics 365 CRM) have pre-configured OAuth credentials managed by airlock. Users simply click Connect and complete the authorization flow — no setup required.

Standard OAuth

Most integrations use standard OAuth. When you add the integration, airlock handles the OAuth flow with the upstream service. Users click Connect on the integration's detail page to authorize access.

No auth

A few public documentation servers — Airbyte and Google Workspace — need no credentials at all. They work as soon as you add them; there is no Connect step.

Manual OAuth Setup

HubSpot, Showpad, and Zoom require you to create your own OAuth application in the service's developer portal first, then enter the client credentials in airlock. Box is similar — each organization enables the Box MCP Server in its own Box Admin Console to generate an enterprise-specific client ID and secret. The wizard shows the redirect URI to register and links to each provider's setup guide.

API Key

Many integrations — including Datadog, Firecrawl, RapidAPI, Dagster+, CodeRabbit, Aikido, ZeroBounce, PhantomBuster, BounceBan, Freshdesk, Process Street, Redmine, and Odoo — use API key or bearer token authentication. Generate a key in the service's settings and enter it on the integration's detail page.

A few integrations ask for two values instead of one, and airlock combines them for you:

• Datadog — an API key and an Application key (both from Datadog's Organization Settings → API Keys / Application Keys).
• Odoo — your Odoo login (email) and your API key.
• Atlassian Goals & Projects — your Atlassian account email and a classic API token.

Redmine uses your personal API key from "My account" → "API access key" on your Redmine instance (the REST API must be enabled by an administrator under Administration → Settings → API).

Atlassian Goals & Projects requires a classic (unscoped) Atlassian API token created at id.atlassian.com — scoped API tokens cannot access the Goals & Projects APIs. Note that a classic token carries your full Atlassian access (including Jira and Confluence), even though this integration only exposes Goals & Projects tools.

Additional Setup

Some integrations need one extra detail when you add them, on top of credentials:

• Showpad and Cognee ask for your workspace subdomain (for example, your-company for your-company.showpad.com).
• Freshdesk asks for your Freshdesk domain (for example, yourcompany for yourcompany.freshdesk.com).
• Redmine asks for your instance URL (for example, redmine.example.com, or tools.example.com/redmine for a subpath install). The instance must be reachable over a public HTTPS address. The instance URL is set once per server and shared by everyone who connects, while each member authenticates with their own API key — so set it to a Redmine host you trust, since every connecting member's key is sent to whatever host is configured.
• Atlassian Goals & Projects asks for your Atlassian site (for example, yourcompany for yourcompany.atlassian.net).
• Azure DevOps asks for your organization name (for example, contoso for dev.azure.com/contoso). The organization must be connected to Microsoft Entra ID (personal-account organizations are not supported) — see Azure DevOps tenant prerequisites below.
• Azure DevOps (token) asks for the same organization name, plus a personal access token — see Which Azure DevOps integration to choose below.
• Dynamics 365 CRM asks for your Dataverse environment host (for example, orgname.crm.dynamics.com).
• Odoo asks for your instance host and database name.
• Dagster+ asks for your deployment URL.
• RapidAPI asks for the API host of the specific API you want to call.

Airlock prompts for these when you add the integration.

Which Azure DevOps integration to choose

There are two Azure DevOps tiles, and they differ only in how you sign in:

Use Azure DevOps (the first one) unless you can't. It is the default: Microsoft runs the server, so new capabilities appear without airlock shipping anything.

Use Azure DevOps (token) when Microsoft sign-in is not available to you — most often because your Azure DevOps organization is not backed by Microsoft Entra ID, or because an administrator cannot grant the consent the first option needs. It covers the same ground: work items (including creating and updating them), queries and WIQL, boards, iterations and capacity, repositories, branches, files and commits, pull requests with their comment threads and reviewers, pipelines and builds with their logs, wikis, test plans, and code, wiki, and work-item search.

Two capabilities of Microsoft's server the token option does not cover:

• Listing your other Azure DevOps organizations. The token option is scoped to the single organization you name when you connect it.
• Downloading binary attachments and build artifacts. Work-item attachments and pipeline artifacts are listed, with their download URLs, but the bytes are not returned through the integration.

Microsoft's Enterprise Live Migration tools are also absent — they are a private preview that most organizations cannot enable on either option.

One place the token option is better: ad-hoc WIQL queries. Microsoft gates wit_query_by_wiql behind an Insiders header on its own server; here query_work_items is available to everyone.

You can connect both at once — they appear as separate integrations.

Azure DevOps tenant prerequisites

The prerequisites in this section apply to the Azure DevOps integration only. Azure DevOps (token) authenticates with a personal access token and needs none of them — create a token in Azure DevOps under User settings → Personal access tokens, scoped to the areas you want the agent to reach, and paste it on the integration's detail page.

Azure DevOps sign-in runs through Microsoft Entra ID, so the Connect flow depends on two applications being present in your company's Entra tenant: airlock's Azure DevOps app and Microsoft's Azure DevOps MCP service. In most tenants both are set up automatically the first time a user consents. A one-time action by an Entra administrator is needed when:

• your tenant restricts user consent to new applications (common in enterprises), or
• Connect fails with an error about a missing service principal (for example, "the app is trying to access a service … that your organization lacks a service principal for").

In either case, an administrator with rights to grant tenant-wide admin consent (for example, a Global Administrator) can approve airlock's Azure DevOps app for the whole tenant by opening this URL and accepting the consent prompt:

https://login.microsoftonline.com/organizations/adminconsent?client_id=c79f31ab-5bae-4405-a728-3e85659584e6

If the administrator's account has access to more than one directory (for example, as a guest or delegated administrator), replace organizations in the URL with the tenant ID or a verified domain of the directory that backs your Azure DevOps organization — the organizations form applies consent in the account's home tenant, which may not be the right one.

After accepting, the browser may land on an airlock sign-in page — the administrator can simply close it (no airlock sign-in is needed for the consent). Then retry Connect in airlock.

If Connect still reports a missing service principal — or the administrator never saw a consent prompt — the administrator can create both applications directly with the Azure CLI (signed in to your tenant):

az ad sp create --id c79f31ab-5bae-4405-a728-3e85659584e6   # Airlock's Azure DevOps app
az ad sp create --id 2a72489c-aab2-4b65-b93a-a91edccf33b8   # Microsoft's Azure DevOps MCP service

Creating the applications does not by itself grant the permission: after running these commands, reopen the admin-consent URL above (or use Entra admin center → Enterprise applications → airlock's Azure DevOps app → Permissions → Grant admin consent) so the tenant-wide grant is recorded, then retry Connect.

Additionally, if your organization uses Conditional Access policies, they can block sign-ins that originate from Microsoft's remote Azure DevOps MCP service. If Connect only fails for users covered by Conditional Access, review those policies with your administrator — Microsoft documents the service's IP addresses that location-based policies may need to allow in the remote MCP server troubleshooting guide.

Adding an Integration

1. Open Integrations in the Control Room
2. Select the integration from the catalog
3. Follow the prompts to add it — the integration is ready to configure
4. Go to the integration's detail page and connect your account (OAuth flow or API key)
5. Configure policies for the tools
6. Copy the MCP URL and add it to your AI client

Syncing Tools

Airlock keeps each integration's tool list aligned with its upstream MCP server, both automatically and on demand.

Automatic detection. On a schedule, airlock checks your connected integrations for upstream tool changes — tools that were added, removed, or changed. When it finds any, it records a notification and applies your organization's newly discovered tools policy, set by an admin under Settings → Security:

The policy applies to every integration in the organization.

Where it shows up. Admins see a notification in the bell menu in the top navigation bar, with an unread count. Opening it lists each integration that changed, along with the added / removed / changed counts; clicking an entry opens that integration's Tools & Policy tab, where you review the changes, unhide tools, and re-sync. (The bell is shown to admins only.)

Manual sync. You can refresh an integration's tools yourself at any time: open its detail page, go to the Tools & Policy tab, and click Sync Tools. This is available for MCP-proxy integrations (including every pre-built one) and for airlock's own built-in surfaces — use it whenever you want to pull the latest upstream tools immediately. Custom OpenAPI integrations have no sync button; their tools are fixed at the spec you deployed.

GitHub and Box are synced manually. Automatic detection isn't available for GitHub or Box integrations — both services issue single-use connection tokens that airlock can't safely reuse from a background job, so it never syncs them on a schedule. After connecting either one, and whenever its tools change, refresh them yourself with Sync Tools on the integration's Tools & Policy tab.