Skip to main content
When you use Glean in a headless way (custom UI, Web SDK, or API-only), users still need to authorize certain data sources (for example, Slack RTS, GitHub) so Glean can access their private data on their behalf.

​
Choosing the right approach

Use this mapping to decide which option to implement based on how your users access Glean:
CohortHow users access GleanRecommended optionStatus
AUsers can log into the Glean web app (app.glean.com or <vanity>.glean.com)Option 1: Glean UIAvailable now
BUsers interact with Glean through an embedded Web SDK experienceOption 2: Web SDK settings componentPlanned
CUsers interact with Glean entirely through your own custom UI built on the Client APIOption 3: checkdatasourceauth APIPlanned
All three options drive the same underlying per-user OAuth state. You can mix them as needed — for example, using Option 1 for admins who are comfortable in the Glean web app and Option 3 for a fully custom “Connect apps” page in your product.

​
Option 1: Glean UI data sources page

Available now
If your users can log into the Glean web app, the easiest path is to have them authorize per-user sources directly in the Glean UI.
Glean data sources settings page showing available and connected data sources

​
What users do

  1. Sign in to Glean in the browser (via SSO or other configured auth).
  2. Navigate to one of:
    • https://app.glean.com/settings/datasources
    • https://<vanity>.glean.com/settings/datasources
  3. Find sources like Slack (RTS) or GitHub and click Connect / Authorize.
  4. Complete the OAuth consent flow with the provider.

​
Why this is preferred

  • No engineering integration work is needed.
  • Works for search, chat, and any API clients that act as that user.
  • Handles Slack RTS and other per-user sources automatically once the user has authorized them.

​
Option 2: Web SDK settings component

Planned — targeted availability: EOD 2/27 PST.
If you already embed Glean via the Web SDK, or you want users to stay entirely inside your app, you can render a settings / data sources component similar to Glean’s own page.
Web SDK data sources component showing available and connected sources

​
Use this when

  • You have a first-class user settings or integrations page in your product.
  • You want a drop-in UI for per-user auth without sending users to the Glean web app.
  • You’re fine using Glean’s UX patterns (labels, flows) in your interface.

​
High-level integration

  1. Initialize the Web SDK so Glean can identify the current user (via your existing auth).
  2. Mount the data sources / settings component on your “Search settings” or “Connect apps” page:
    • It lists per-user data sources that need auth for the active user.
    • It shows a Connect / Authorize button for each.
  3. When the user clicks Connect, the Web SDK:
    • Starts the appropriate OAuth flow (e.g. Slack, GitHub).
    • Handles redirects and token storage via Glean.
  4. After completion, the component refreshes and marks the source as connected.

​
Option 3: checkdatasourceauth API

Planned — targeted availability: EOD 2/26 PST.
For API-only or highly customized headless integrations, you can call the Client API to discover which data source instances require per-user OAuth, then build your own UI around that.
See the datasources-demo-app for a working example that uses this API to render a page where users can authorize their data sources.

​
Endpoint

FieldValue
MethodPOST
Path/rest/api/v1/checkdatasourceauth
Base URLhttps://{instance}-be.glean.com
AuthBearer Client API token for the authenticated user or service

​
Response

The endpoint returns a CheckDatasourceAuthResponse containing an array of unauthorizedDatasourceInstances. Each entry includes:
FieldDescription
datasourceInstanceInstance identifier (e.g. slack_0, github_enterprise_0)
displayNameHuman-readable name (e.g. “Slack”)
authStatusCurrent per-user auth status: DISABLED, AWAITING_AUTH, AUTHORIZED, STALE_OAUTH, or SEG_MIGRATION
authUrlRelativePathRelative OAuth URL for this user + instance, including a one-time transient token

​
Example response

{
  "unauthorizedDatasourceInstances": [
    {
      "datasourceInstance": "slack_0",
      "displayName": "Slack",
      "authStatus": "AWAITING_AUTH",
      "authUrlRelativePath": "/auth/slack/oauth?transient_auth_token=..."
    }
  ]
}

​
Example request

curl -X POST \
  "https://$GLEAN_INSTANCE-be.glean.com/rest/api/v1/checkdatasourceauth" \
  -H "Authorization: Bearer $GLEAN_API_TOKEN" \
  -H "Accept: application/json"
  • GLEAN_INSTANCE is your tenant instance ID (e.g. acme).
  • GLEAN_API_TOKEN is a Client API token that authorizes calls on behalf of the user.

​
Building your own “Connect apps” UI

A typical headless flow:
  1. Call checkdatasourceauth as the current user.
  2. For each item in unauthorizedDatasourceInstances:
    • Render something like: “Connect Slack”, “Connect GitHub”.
    • Construct the full OAuth URL: https://{instance}-be.glean.com{authUrlRelativePath}
  3. When the user clicks Connect:
    • Redirect them (or open a popup) to that URL.
    • They’ll see Glean’s consent screen and then the provider’s OAuth consent.
  4. After success:
    • Show a “Connected” confirmation in your UI.
    • Optionally call checkdatasourceauth again and verify that the instance no longer appears in unauthorizedDatasourceInstances.
Once a source is authorized, search, chat, and other Client API calls for that user will start including data from that source (for example, Slack RTS conversations), subject to permissions.

​
Reauthorization

For most data sources, OAuth is effectively “set it and forget it”: Glean receives a long-lived refresh token and uses it to keep access tokens up to date automatically. Users only need to reauthorize if the provider revokes or expires the refresh token (for example, they revoke the app, their org rotates apps, or the provider enforces a new consent). When that happens, Glean surfaces the source as needing authorization — in the data sources settings UI (Options 1 and 2) or via the checkdatasourceauth endpoint (Option 3) — so you can prompt users to reconnect.