Version 3.0
How connections get set up

How connections get set up

Not every integration is set up the same way. Three patterns cover all of them.

Audience: IT (the enabler) and builders

The three stages

Stage 1: Organizational prerequisite. A one-time setup that has to exist before anyone in your org can connect. Could be a Microsoft Entra app registration, a Google Cloud project with OAuth client, a GitHub App install, or a Slack workspace install. Not every integration has a stage 1.

Stage 2: Credential creation. The actual OAuth dance or API key paste. For OAuth, this happens per user. For API keys, it is one paste by whoever holds the key.

Stage 3: Project binding. Attaching an existing credential to a Project so the agent can use it. Always done by the builder.

The three actors

  • IT. Owns enterprise identity, Microsoft and Google Cloud admin consoles, and platform governance.
  • Functional admin. Holds Ramp and Stripe admin access, sometimes Slack workspace admin. Often a Finance leader, not IT.
  • Builder. Anyone authoring Projects, Apps, and Data Collections.

The three setup patterns

Self-serve OAuth

No stage 1. The platform owns the OAuth application on its side. A builder OAuths their own account and is done.

Examples: Linear.

Admin-enabled OAuth

Stage 1 is IT. Stage 2 can be any authorized user, including a builder OAuthing their own account.

Examples: SharePoint, Microsoft Teams, OneDrive, Outlook (mail and calendar), Google Drive, Gmail, Google Calendar, GitHub, Slack.

The non-obvious part of admin-enabled OAuth: once stage 1 is done, builders self-serve at stage 2. The org-level work is a foundation, not a permanent gate.

Admin-only API key

No per-user OAuth. A functional admin (usually Finance) generates a restricted API key and pastes it. Builders bind to that single credential.

Examples: Ramp, Stripe, Exa.

What this means for you

If you are IT, your work concentrates at stage 1. Once stage 1 is done for an admin-enabled OAuth provider, you can step back and let builders self-serve.

If you are a functional admin, you own stage 2 for admin-only API key providers.

If you are a builder, you OAuth your own account on self-serve providers and on admin-enabled providers once IT has done the foundation. You always do stage 3.

Each per-provider setup page begins with a "Who connects this" block that names the actor for each stage and the artifact each stage produces.