Set up custom OAuth applications for integrations, assign clients to your workspace or user groups, and control scopes, tenant policies, and branding.
You can use multiple custom OAuth clients for the same integration. Set one client for your entire workspace and assign additional clients to specific user groups. This lets different groups use the same integration with different OAuth clients.
When you configure a custom OAuth client, Langdock routes new authentication flows through the OAuth application assigned to each user instead of the default Langdock client. A client for the entire workspace applies by default, while group clients apply to members of the assigned groups. This means:
Your branding (custom name and logo) appears in consent screens
Your tenant policies control user access and admin consent requirements
Your rate limits apply to API calls made by your users
Your user groups can authenticate through separate OAuth clients
1
Create OAuth App at Provider
Register a new OAuth application in your provider’s developer portal (Google Cloud Console, Microsoft Azure, etc.).Required Configuration:
Copy the exact redirect URL from Langdock’s integration settings
Select all required scopes shown in Langdock for that integration
Configure any tenant-specific settings (admin consent, allowlisting)
2
Gather Credentials
Note down the following from your OAuth app:
Client ID (always required)
Client secret (required for most integrations)
Tenant ID (optional, shown for Microsoft integrations only)
3
Configure in Langdock
Go to Workspace settings → Integrations, select the integration, and scroll to Bring your own OAuth Client.Click Add another OAuth client when the integration includes a Langdock client. If the integration requires your own client, click Configure your OAuth client to use this integration.In the configuration dialog, copy the Redirect URL into your OAuth app and review the Scopes section. Make sure all listed scopes are enabled in your OAuth app — missing scopes will cause an insufficient scopes error. You can copy all scopes at once using the copy button.For integrations with action-level permissions, we recommend keeping Sync scopes with enabled actions turned on by default. Langdock then requests the auth scopes plus the scopes required by enabled or shared actions, keeping requested scopes aligned with the actions your workspace can use. Learn more in Manage Action-Level Scopes.Optionally add a descriptive Client name. Under Access, choose Entire workspace or Groups. Enter your Client ID and Client secret (and Tenant ID if prompted for Microsoft integrations), then click Save and confirm the change.Select the saved client from the client list and confirm the switch to activate it.
Once active, new connections for users with access to this client use it immediately and only work if the credentials are valid. Existing connections remain linked to the client they were created with.
Use group access when different parts of your organization need separate OAuth applications for the same integration. For example, assign one client to a subsidiary with its own Microsoft Entra tenant, or use a separate client when a department needs a different approved scope set. The client for your entire workspace remains the default for everyone who is not covered by a group client.
1
Add another custom client
Click Add another OAuth client. Optionally give the client a descriptive name so you can identify it in the client list.
2
Manage client access
In the Access section, select Groups, then click Manage to choose the user group that should use this client.
3
Add credentials
Enter the Client ID, Client secret, and any fields required by the provider. Click Save and confirm the change. Select the saved client from the client list and confirm the switch to activate it.
Keep a client active for the entire workspace if users without a group client need to connect. A user cannot belong to groups assigned to two active OAuth clients for the same integration.
The redirect URL must match exactly. Any mismatch will cause redirect_uri_mismatch errors. The exact domain depends on your Langdock deployment — always copy the redirect URL from the dialog rather than constructing it manually.
Displays the OAuth scopes required for the integration to function correctly. For example, Jira requires scopes like read:jira-work, write:jira-work, read:jira-user, offline_access, and manage:jira-configuration.
Copy: Copy all scopes to your clipboard for pasting into your OAuth app configuration.
Edit: Switch to edit mode to customize scopes in a text area (advanced use cases only).
Reset to default scopes: Restore the original scope list if you have modified it.
For integrations with action-level permissions, keep Sync scopes with enabled actions turned on unless you intentionally want to manage a fixed scope list yourself. This is the recommended default because Langdock can keep OAuth scopes in sync with enabled and shared actions.
All listed scopes must be enabled in your OAuth app. Missing scopes will cause insufficient_scope errors when users try to connect.
Enter your OAuth application credentials:
Client name (optional): A descriptive name that identifies the client in Langdock
Client ID (required): Your app’s public identifier
Client secret (required for most integrations): Your app’s private key, stored encrypted
Tenant ID (Microsoft integrations only, optional): Your Azure AD tenant identifier
Each card shows the client name, access type, scope mode, and active status.
Select an inactive client card to activate it.
Select an active custom client card to deactivate it.
Click the settings icon to edit the client.
Open the client settings and click Delete OAuth client credentials to remove it.
Select Langdock client to use the managed client for new connections. This deactivates all custom clients.
You can keep several group clients active when their members do not overlap. Only one client for the entire workspace can be active for an integration.
Deactivating a client stops new connections from using it. Existing connections remain linked to their selected client. If you delete a client, existing access tokens can continue working until authentication fails. Users must then reauthorize with an eligible active client.
Some of our integrations can only be used when providing your own OAuth client. Details on how to connect them with Langdock are described in this section.
To enable this integration for your workspace, your ServiceNow system administrator must create an OAuth client, in the form of an application registry in ServiceNow, following this documentation. Required authentication fields
Provide ServiceNow Subdomain
When a user wants to create a connection with ServiceNow, they have to provide the subdomain of your ServiceNow instance.
Are self-hosted or cloud-hosted accounts supported?
Only Cloud-hosted accounts are currently supported.
Is a paid ServiceNow plan required?
A paid ServiceNow account is required to create an application registry. View ServiceNow’s plans here.
Are any special account permissions / roles required?
Yes. To connect by OAuth, your systems administrator should set up the right configuration within your instance to connect any user using an OAuth connection. E.g. all users need the oauth_user role to be able to connect. Learn more about ServiceNow’s groups and permissions
Are there usage limits?
Yes. ServiceNow implements rate limiting to prevent excessive API usage. System administrators can configure rules that restrict the number of inbound REST API requests processed per hour. Learn more about ServiceNow’s usage limits.
Shopify Admin has no Langdock managed OAuth app. A workspace admin creates an app in the Shopify Dev Dashboard and pastes the Client ID and Client Secret into Langdock. Connections use application-level permissions: Langdock acts with the app’s Admin API scopes, not the personal Shopify role of the person who installed it.
Show how to configure a Shopify Admin OAuth client
Configuring your own OAuth client for Snowflake gives you control over authentication policies, token validity periods, and IP allowlisting within your Snowflake environment.
Show how to configure a Snowflake OAuth client
Required Information:
OAuth Redirect URL: Copy this from Langdock’s Snowflake integration settings page
Client ID: Generated by Snowflake after creating the security integration
Client Secret: Generated by Snowflake after creating the security integration
Authorization URL: Your Snowflake account’s authorization endpoint
The Redirect URL from Langdock must be provided in Snowflake, while the Client ID, Client Secret, and Authorization URL from Snowflake must be entered into Langdock’s integration settings.
If your Snowflake account has network policies or IP allowlisting enabled, you may need to whitelist Langdock’s static IP address to allow connections. See Static IP Configuration for details.
Replace <integration_name> with a descriptive name and <your_redirect_uri> with the OAuth Redirect URL from Step 1.
Run the query to create your new security integration in Snowflake.
Note: Adjust your OAUTH_REFRESH_TOKEN_VALIDITY value based on your security policies.
3
Retrieve Client ID and Client Secret
Show how to retrieve your Client ID, and Secret from Snowflake
Within the same workspace, run the following query: