Guides

Creating Integrations

Set up custom OpenAPI integrations, MCP proxies, and built-in 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:

TypeDescriptionHow to Create
Pre-built IntegrationConnect to a popular service (GitHub, Linear, Notion, etc.) — Airlock proxies the service's MCP server (the provider's own, or an Airlock-hosted one for services without one)Select from the integrations list
Custom OpenAPIAny REST API with an OpenAPI specPaste your OpenAPI spec
Knowledge GraphPer-organization graph store for entities and relationships, queried via the memory_* tool familySelect "Knowledge Graph" type
airlock code graphIndex your GitHub repositories and let agents query architecture, call graphs, in-repo and cross-repo referencesSelect "airlock code graph" type and install the GitHub App

Creating an Integration

From the Control Room

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

Pre-built Integrations

Select from 50+ 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. Enter a Name for your integration
  2. Paste your OpenAPI Specification (YAML or JSON)
  3. Optionally set a custom auth header name if your API doesn't use a Bearer token
  4. Continue through the wizard to configure policies and finish

The Target URL (the base URL where Airlock sends requests) is set after creation on the integration's detail page under Credentials — see Target URL below.

OpenAPI Specification

Airlock uses OpenAPI specifications to understand your API's structure:

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

Each operation in your OpenAPI spec must have an operationId. This becomes the tool name in MCP:

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

Knowledge Graph Integration

A Knowledge Graph integration is a per-organization graph 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. Start a new integration and select the Knowledge Graph type
  2. Give it a name and finish the wizard

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. Start a new integration and select the airlock code graph type
  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 — indexing kicks off automatically

The first sync takes a few minutes for typical repositories; subsequent updates run incrementally on every push. The Repositories tab on the integration's detail page shows sync status per repo and lets you trigger a manual re-sync.

Integration Configuration

Target URL

The target URL is where Airlock sends requests. This can differ from the URL in your OpenAPI spec:

  • OpenAPI servers[0].url: Documentation/design time URL
  • Airlock Target URL: Runtime URL for actual requests

This allows you to:

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

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

After updating an OpenAPI spec, use the Sync Tools button on the integration's Tools tab to refresh the available tools list. Airlock also checks connected integrations for upstream tool changes automatically and notifies admins — see Syncing Tools for the full flow. GitHub integrations are the exception: their tools must be synced manually.

Managing Integrations

Editing

Click on an integration to view and edit its configuration:

  • Update the OpenAPI specification
  • Change the target URL
  • Modify policies
  • Manage user credentials

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