What Are Airlock Apps?

How registered enforcer applications relate to the Integrations Gateway, credentials, and user consent.

Developer Guide — register & integrate Gateway client SDKs (source)

Enforcer apps on the platform

An Airlock App (also called an enforcer app) is a record you create in the Airlock Platform under Developer Programme → My Apps. It represents your integration — a plugin, automation, IDE extension, or custom tool — that talks to the Integrations Gateway to send approval requests to the mobile approver.

When you register an app, you receive an App ID, a Client ID, and (for confidential client types) a Client Secret that is shown only once. Those values are how the gateway knows which product is calling and which OAuth rules, origins, and consent state apply.

Why a Client ID?

Every gateway request from a third-party enforcer is attributed to a registered app via X-Client-Id (and, for public clients, origin validation). The Client ID lets Airlock:

  • Bind traffic to the correct app registration and developer programme profile.
  • Enforce the right client type (public vs confidential) and allowed OAuth flows.
  • Resolve user consent — the user approves a specific app identity, not an anonymous client.

Why a Client Secret?

Confidential app kinds (for example Agent, Desktop, and VS Code extension enforcers) cannot rely on a browser origin alone. They send X-Client-Secret alongside the Client ID so the gateway can verify that the caller possesses the secret issued when the app was registered. That pattern matches common OAuth confidential-client practice: secrets must live only in components you control (servers, native binaries, secure storage), not in public web assets.

Public clients (typical Web and Mobile enforcer UIs) use Client ID plus origin validation instead of a long-lived secret, because embedded secrets would be extractable from the client.

User identity is separate from the app

App credentials identify the product. Most operations are still user-scoped: the gateway also needs to know which user the enforcer is acting for. That is usually supplied with a Personal Access Token (X-PAT, recommended) or an OAuth Bearer access token after sign-in. The gateway checks PAT first, then falls back to Bearer. See the Developer Guide for the full lifecycle.

How users give consent

Before your enforcer can submit artifacts or complete certain flows, the user must consent to your app. During that flow, information from your developer programme profile (such as name, organization, and contact details) may be shown so the user understands who operates the integration.

Your integration should call the gateway consent check (for example GET /v1/consent/status via the SDK’s checkConsent) before relying on approval workflows. Typical outcomes include:

  • Approved — the user has consented; you can proceed with pairing, heartbeats, and artifacts as described in the Developer Guide.
  • Consent required / pending / denied — the API returns error codes such as app_consent_required, app_consent_pending, or app_consent_denied. Your UI should prompt the user to complete or review consent (the response may include a consent URL where applicable).

What to read next

For joining the programme, registering an app, app-kind tables, HTTP examples, and the full enforcer lifecycle (discovery, PAT, pairing, heartbeats, artifacts), use the Developer Guide. For language-specific APIs, see Gateway Client SDKs.