Creating Integrations

An integration in airlock represents an API or service you want to expose to AI agents through the MCP protocol.

Integration Types

Airlock supports several integration types:

There is no separate type picker — every integration starts from the catalog on the Integrations page. Airlock's own surfaces and the 190+ pre-built services are cards in the catalog; the OpenAPI and MCP Proxy tiles at the head of the Available grid are the entry points for bringing your own API or MCP server.

Creating an Integration

Creating integrations requires an organization admin. Members with the USER role see only the integrations an admin has given them access to — the catalog and the creation entry points are hidden for them, and the API rejects creation with Admin access required.

From the Control Room

1. Open Integrations from the left sidebar
2. Connect a pre-built integration from the catalog, or click the OpenAPI tile (custom REST API) or the MCP Proxy tile (wrap an existing MCP server)
3. Follow the wizard to finish creating the integration

Pre-built Integrations

Select from 190+ pre-configured integrations. These come with tools already defined — no OpenAPI spec needed. See Pre-built Integrations for the full list.

Custom OpenAPI Integration

For custom REST APIs:

1. Paste your OpenAPI Specification (YAML or JSON). On the same screen, optionally set a custom auth header name if your API doesn't use a Bearer token.
2. Click Analyze & Configure Policies — airlock parses the spec and extracts the tools.
3. On the Configure Policies step, review the Name (auto-filled from the spec's title — edit it if you like) and choose which tools require approval before they run. For every tool you flag, pick at least one approver (a user or a group) or turn on self-approval — airlock will not let you deploy while a flagged tool has no approver.
4. Click Deploy Tools to finish creating the integration.

The Target URL (the base URL where airlock sends requests) is optional — see Target URL below.

MCP Proxy Integration

To put airlock's policies, approvals, and audit trail in front of an MCP server that isn't in the catalog:

1. Click the MCP Proxy tile at the top of the catalog.
2. Give the connection a name and paste the MCP server's URL. It must be HTTPS.
3. Click Add MCP. Airlock probes the server to work out how it authenticates:
   • OAuth with dynamic client registration — you're sent straight to the provider's consent screen.
   • OAuth requiring a pre-registered app — airlock asks for your own OAuth Client ID and Client Secret, then continues.
   • API key, or no auth at all — you land on the integration's Credentials tab; paste the key there and the tools sync automatically.

OpenAPI Specification

Airlock accepts OpenAPI 3.0, 3.1, and 3.2, in YAML or JSON. Swagger 2.0 documents are rejected — convert them to OpenAPI 3 first (for example in editor.swagger.io via Edit → Convert to OpenAPI 3) and paste the result. Tools are generated from get, post, put, delete, and patch operations; other methods are ignored.

openapi: 3.0.0
info:
  title: My API
  version: 1.0.0
servers:
  - url: https://api.example.com
paths:
  /users:
    get:
      operationId: list_users
      summary: List all users
      responses:
        '200':
          description: List of users
    post:
      operationId: create_user
      summary: Create a new user
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                name:
                  type: string
                email:
                  type: string

Operation IDs

Give every operation an operationId — it becomes the tool name agents see in MCP:

• operationId: list_users becomes a tool called list_users
• operationId: create_user becomes a tool called create_user

It is optional. An operation without one gets a name derived from its method and path (get_users_id), which is harder for an agent to interpret. Tool names are capped at 64 characters and truncated beyond that, so keep operationId values short.

airlock memory integration (Knowledge Graph)

An airlock memory integration is a per-organization knowledge graph — a store for entities and the relationships between them. It comes pre-wired with the memory_* tool family — search, get/explore entities, link/archive/delete, batch create, schema introspection, and read-only SQL queries over the graph's nodes and edges views.

To create one:

1. On the Integrations page, click the airlock memory card in the catalog
2. Review which memory tools require approval (the write tools — create, update, link, archive, delete — are pre-selected), then click Deploy Tools. The name is fixed to airlock memory.

The schema is layered — entities live in one of four layers (semantic, temporal, procedural, code) with conventional types like Person, Project, Document, Event, Decision, and Workflow. The schema grows on demand: when an agent writes a new PascalCase entity or relationship type, it's registered automatically. You do not need to seed types up front. Storage is backed by Parquet files on S3 and queried with DuckDB — you do not need to run or manage any database yourself.

airlock code graph integration

An airlock code graph integration indexes one or more of your GitHub repositories and exposes them to agents as a queryable code-intelligence surface. Agents can ask questions like "which functions call chargeCustomer?", "what's the call graph for the checkout flow?", or "who depends on this module across repos?" without you writing any tools.

To create one:

1. On the Integrations page, click the airlock code graph card in the catalog (the name is fixed to airlock code graph)
2. On the integration's detail page, install the airlock Code GitHub App to grant read access to your repositories
3. Choose which repositories to track
4. Click the sync icon next to a repo (or Sync all) to run the first index
5. Turn on Auto-sync for each repo you want re-indexed whenever someone pushes to it — it is off by default

The first sync takes a few minutes for typical repositories; with auto-sync on, later pushes trigger incremental updates. The Repositories tab on the integration's detail page shows sync status per repo and lets you trigger a manual re-sync at any time.

Integration Configuration

Target URL

The target URL is the base URL airlock actually sends requests to. It is optional: if you leave it unset, airlock uses the first entry in your spec's servers list.

Set one (on the integration's detail page under Credentials, admin only) when you want to point the integration somewhere other than what the spec says:

• Use different environments (staging, production)
• Route through internal networks
• Add path prefixes

If your spec declares no servers and no target URL is set, calls will fail.

Authentication

Each user connecting to an integration provides their own API credentials:

• OAuth: For services that support OAuth flows (GitHub, Google Calendar, etc.)
• API Key / Bearer Token: For services that use static credentials

See Authentication for details.

Syncing Tools

Sync Tools on the integration's Tools & Policy tab refreshes the tool list for MCP-proxy integrations (including every pre-built one) and for airlock's own built-in surfaces. Custom OpenAPI integrations have no sync button — their tools are fixed at the spec you deployed.

Airlock also checks connected integrations for upstream tool changes automatically and notifies admins — see Syncing Tools for the full flow. GitHub and Box are the exceptions to the automatic check: their tools must be synced manually.

Managing Integrations

Editing

Click on an integration to view and edit its configuration:

• Rename the integration and edit its categories (Settings tab)
• Set the target URL (Credentials tab)
• Change which tools require approval, hide tools, and override tool descriptions (Tools & Policy tab)
• Manage your own API credentials (Credentials tab)

The OpenAPI specification itself cannot be replaced after creation. If your API's spec changes, create a new integration from the updated spec and delete the old one.

Deleting

1. Click on the integration to open the detail page
2. Open the Settings tab (admin access required)
3. In the danger zone, click the Delete MCP button

Warning: Deleting an integration removes all associated policies, access tokens, and pending requests.

Best Practices

Operation Naming

Use consistent, descriptive operation IDs:

# Good
operationId: list_orders
operationId: get_order_by_id
operationId: create_order
 
# Avoid
operationId: op1
operationId: getOrder  # Inconsistent casing

Security

• Never include credentials in the OpenAPI specification
• Use HTTPS for all target URLs
• Regularly rotate API credentials