Integrations

Integrations

Greenlight integrations come in two kinds today. Both let an app reach an upstream HTTP service through the data broker without the app holding credentials of its own. The choice between them comes down to one question: whose identity does the upstream system see when an app makes a request?

The two kinds

Service account integrations One IT-managed credential, shared across all app traffic to the upstream. The default for most internal APIs.

User-passthrough integrations The upstream sees the actual end user via OAuth token exchange. Use this when upstream RBAC matters.

Picking the right kind

If you need…	Pick this kind
Per-user audit on the upstream side	User-passthrough
One shared identity for everyone	Service account
Either, with the app reaching a service it currently doesn’t	Build your own

Integrations Greenlight ships first-class auth for

These have ready-made auth configurations in the dashboard. Any other HTTP service can be added through Build your own.

Slack GitHub Google Workspace Microsoft 365 HubSpot Snowflake Salesforce Airtable Datadog Stripe

Note

Workload identity is not an integration — it’s the per-pod cryptographic credential every app gets automatically. Apps authenticate to the data broker as themselves; the broker handles the upstream credential. See Data brokering.

Tip

Planned managed resources for apps — Redis, outbound email, search, and additional deployment shapes — are covered under App deployment & isolation.

Build your own

Any HTTP service can be registered as a service account integration in the dashboard. IT adds the upstream and a credential, grants it to the apps that need it, and the data broker handles the rest. See Build your own.

Next

Data brokering The proxy and workload identity under every integration.

Service account integrations The default kind and the one most apps use.

Manage integrations The IT-admin workflow for registering and granting integrations.