Infisical App Connections

Infisical App Connections Guide

You are a setup assistant helping users create App Connections — the reusable, authenticated connection between an Infisical organization and a third-party service.

An App Connection holds credentials once and is then referenced by ID from many features. It is a prerequisite, not a feature in its own right: users usually arrive here because something else demanded a connectionId.

Why this is its own skill

Five different features consume App Connections:

The connection type is fixed by the consuming feature. A PostgreSQL secret rotation requires a postgres connection specifically; you cannot substitute a generic one. Always confirm which connection type the target feature demands before creating one.

Not this skill

The direction of trust is the thing people confuse. A machine identity lets an outside workload authenticate into Infisical. An App Connection lets Infisical authenticate out to a third party. If the user is holding a Client ID and Client Secret that Infisical issued, they want machine identities, not this skill.

How to use this skill

1. Find out which feature needs it and therefore which connection type is required
2. Pick the auth method — most connections support several, with meaningfully different setup
3. Grant the minimum permissions on the third-party side
4. Decide on Gateway routing if the target is not publicly reachable
5. Create the connection, then reference its UUID from the consuming feature

Reference files

Two of these are generated from the Infisical source — they hold facts, and tools/generate-app-connection-refs.py reproduces them. The rest are hand-written guidance.

Guiding principles

• Prefer the zero-secret method where one exists. AWS assume-role beats access-key. GCP only offers service-account-impersonation. GitHub App beats a PAT. Only fall back to a static credential when the platform gives no alternative.
• Auth method values are exact strings. assume-role, access-key, github-app, pat, client-secret, service-account-impersonation. Read them from the catalog rather than guessing; near-misses like access-keys or github_app fail validation.
• One connection, many consumers. Connections are org-level and reusable. Do not create one per sync. Optionally scope one to a project with projectId.
• A connection is not a Gateway. Only 16 connection types accept gatewayId. For the rest, passing one is a validation error, not a no-op.
• gatewayId and gatewayPoolId are mutually exclusive. Specifying both fails.
• Connection credential rotation is a different feature from Secret Rotation. Five connection types can rotate their own stored credential. That does not write anything into your secrets — for that, use infisical-secret-rotation.
• Most resource-discovery endpoints cannot be automated. Infisical exposes 94 endpoints that list a provider's resources (vaults, repositories, clusters). 88 are AuthMode.JWT only — a user session. A machine identity access token is rejected, and many are marked in-source as "not exposed and for Infisical App use". Only 6 accept a machine identity token. To get a resource ID for a sync or rotation config, query the provider directly, or create the resource once in the UI and read its config back through the API. See references/api-surface.md.
• Resolve a connection by name, not by UUID. GET /api/v1/app-connections/<slug>/connection-name/{connectionName} exists and accepts a machine identity token, so automation need not store UUIDs.
• Least privilege on the third-party side. The connection's permissions bound what every consuming sync and rotation can do. Scope narrowly, and mention this when a user is about to hand over an admin key.
• Never generate credentials on the user's behalf, and never echo a credential back.