Service account integrations

Integrations

A service account integration is the default kind. IT registers an upstream HTTP service in the dashboard, attaches a credential to it, and grants it to apps that need it. Every call from those apps goes through the data broker, which substitutes the credential at the request edge.

The upstream system sees one identity — the service account — regardless of which app or end user produced the request. Per-end-user attribution lives in Greenlight’s audit log, not in the upstream system.

When to use this kind

Service account integrations cover the majority of internal SaaS and HTTP APIs. They are the right choice when:

• The upstream system doesn’t natively enforce per-user permissions on its API, or
• Per-user enforcement isn’t required for the use case, or
• The integration is fundamentally org-level (a shared Slack workspace, a shared GitHub organization).

If the upstream system does enforce per-user permissions and you want those to apply to Greenlight apps, use User-passthrough integrations instead.

Common service account integrations

The integrations below ship with first-class auth configuration. Any other HTTP service can be added through Build your own.

Integration	Auth mechanism
Slack	Workspace OAuth install
GitHub	GitHub App install scoped to an organization
Google Workspace	Domain-Wide Delegation service account
Microsoft 365	App-only OAuth client credentials
Close (CRM)	API key
Fireflies	API key
Generic REST	Bearer, basic, or client-credential OAuth

What an app sees

The app code is plain HTTP against the proxy URL. The path after the integration name is forwarded verbatim to the upstream.

// Post to Slack
await fetch(
  `${process.env.GREENLIGHT_PROXY_URL}/slack/api/chat.postMessage`,
  {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ channel: '#alerts', text: 'Build complete' }),
  }
);

The app does not need to know that the call is being authenticated as a workspace token, or that the request body is being augmented with anything. The broker handles it.

Note

The upstream system’s logs will show the shared service account as the actor on every call. Per-end-user attribution — which user’s Greenlight session caused this call — lives in Greenlight’s audit log.

Operating a service account integration

The IT-admin workflow lives in Manage integrations. Briefly:

1. Add the integration in the dashboard.
2. Attach a credential (paste a token, complete the install flow, or upload a service-account JSON).
3. Grant the integration to apps that need it.
4. Rotate credentials when your org’s rotation policy says to. The integration stays available across rotation.

Revoking an integration revokes it everywhere instantly. Every app that depends on it loses access on the next call, with a structured error the app can handle.

Next

Integrations overview All three kinds and the decision criteria.

User-passthrough integrations When the upstream system needs to see the actual end user.

Manage integrations The IT-admin workflow.