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)
Enterprise deployment. Configure integrations against your organization's Gateway at https://<your-gateway-host> and identity at https://<your-auth-host>/realms/<your-realm>. See the Getting started and Developer Guide.

Enforcer apps in your deployment

An Airlock App (also called an enforcer app) is a registered integration in your enterprise deployment. Your platform administrator creates the record in the enterprise admin console and issues a Client ID and (for confidential clients) a Client Secret. It represents your product — a plugin, automation, IDE extension sample, or custom tool — that talks to the Integrations Gateway at https://<your-gateway-host> to route approval requests to the Mobile Approver.

Those credentials are how the gateway knows which integration is calling and which OAuth rules, origins, and consent state apply.

Why a Client ID?

Every gateway request from a Host 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 app registration 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 app registration 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 enterprise deployment setup, 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.