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:
| Type | Description | How to Create |
|---|---|---|
| Pre-built Integration | Connect 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 OpenAPI | Any REST API with an OpenAPI spec | Paste your OpenAPI spec |
| Knowledge Graph | Per-organization graph store for entities and relationships, queried via the memory_* tool family | Select "Knowledge Graph" type |
| airlock code graph | Index your GitHub repositories and let agents query architecture, call graphs, in-repo and cross-repo references | Select "airlock code graph" type and install the GitHub App |
Creating an Integration
From the Control Room
- Open Integrations from the top navigation
- 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)
- 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:
- Enter a Name for your integration
- Paste your OpenAPI Specification (YAML or JSON)
- Optionally set a custom auth header name if your API doesn't use a Bearer token
- 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: stringOperation IDs
Each operation in your OpenAPI spec must have an operationId. This becomes the tool name in MCP:
operationId: list_usersbecomes a tool calledlist_usersoperationId: create_userbecomes a tool calledcreate_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:
- Start a new integration and select the Knowledge Graph type
- 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:
- Start a new integration and select the airlock code graph type
- On the integration's detail page, install the Airlock Code GitHub App to grant read access to your repositories
- 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
- Click on the integration to open the detail page
- Open the Settings tab (admin access required)
- 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 casingSecurity
- Never include credentials in the OpenAPI specification
- Use HTTPS for all target URLs
- Regularly rotate API credentials