What Are Connections?
A connection is a saved authentication link between Langdock and an external tool. When you connect your Google Calendar, HubSpot, or any other integration, you’re creating a connection that stores the credentials needed to interact with that service.
Each connection belongs to the user who created it. This ensures your credentials remain secure and actions are performed with your access rights.
Authentication Types
Langdock supports different authentication methods depending on the integration:
| Auth Type | How It Works | Example Integrations |
|---|
| OAuth | You sign in directly with the service and grant Langdock permission | Google Suite, Microsoft 365, Slack, HubSpot |
| API Key | You provide an API key from the service | OpenAI, Stripe, custom integrations |
| Service Account | An admin sets up a service-level account | BigQuery, some enterprise tools |
| None | No authentication needed | Public APIs |
OAuth Authentication
Most popular integrations use OAuth, the industry-standard protocol for secure authorization. When you connect via OAuth:
- You’re redirected to the service’s login page (e.g., Google, Microsoft)
- You sign in with your own account
- You grant permissions for Langdock to access specific data
- Tokens are stored securely and refreshed automatically
OAuth connections always act with your permissions. If you can’t access a calendar in Google, the assistant using your connection can’t access it either.
API Key & Service Account Authentication
These authentication types require you to manually provide credentials:
- API Key: Copy an API key from the service’s settings and paste it into Langdock
- Service Account: Provide service account credentials (often a JSON file or key pair)
These are typically used for services that don’t support OAuth or for admin-level integrations that need broader access.
Connection Ownership
By default, connections are user-based and not shareable. This means:
- ✅ You can only see and use connections you created
- ✅ Actions performed use your access rights and permissions
- ✅ Your credentials are never exposed to other users
- ❌ Other users cannot directly use your OAuth connections
This design ensures security and compliance—your authorization remains yours.
Why User-Based?
When you authorize Langdock to access your Google Calendar, you’re granting permission for actions to be performed as you. Sharing that connection with others would mean they could act on your behalf, which violates the trust relationship established during OAuth consent.
Sharing Connections via Assistants
While connections are personal by default, there’s a powerful way to share their capabilities: attaching connections to assistants.
How It Works
When you create an assistant and add actions:
- Add an action to your assistant (e.g., “Create Calendar Event”)
- Select a connection to use with that action
- Share the assistant with others
Now anyone using that assistant can trigger the action using your pre-configured connection—without ever seeing your credentials.
Example: You create a “Team Calendar Assistant” with a “Create Event” action linked to your Google Calendar connection. When a colleague uses this assistant to schedule a meeting, the event is created in your calendar using your credentials—but they never see your OAuth tokens.
Use Cases
- Team assistants: Create a shared assistant that can add events to a team calendar using your connection
- Workflow automation: Set up workflows where actions run with your credentials
- Departmental tools: Build assistants that interact with your CRM or project management tools
When sharing assistants with pre-configured connections, the actions will be performed using your account. Only attach connections you’re comfortable having others trigger.
Sharing Non-OAuth Connections Directly
Connections that use API Key, Service Account, or No Authentication can be shared directly with other users, groups, or your entire workspace.
Shareable Connection Types
| Auth Type | Directly Shareable? |
|---|
| OAuth | ❌ No |
| API Key | ✅ Yes |
| Service Account | ✅ Yes |
| None | ✅ Yes |
Why OAuth Can’t Be Shared Directly
OAuth tokens represent a specific user’s authorization and consent. Sharing them would:
- Violate the user’s agreement with the service provider
- Create security risks if tokens are leaked
- Make it impossible to track who performed which action
How to Share Non-OAuth Connections
If you have an API key connection (or another shareable type), workspace admins and connection owners can share it:
- Go to Integrations in your settings
- Find the connection you want to share
- Click Share and select recipients:
- Specific users: Share with individual team members
- Groups: Share with entire teams or departments
- Workspace: Make available to everyone
This is great for shared API keys like translation services, analytics tools, or internal APIs that the whole team should be able to use.
Who Can Share Connections?
| Role | Can Share |
|---|
| Connection owner | ✅ Their own non-OAuth connections |
| Workspace admin | ✅ Any non-OAuth connection in the workspace |
| Regular user | ❌ Only through assistants |
Choosing the Right Sharing Method
| Scenario | Recommended Approach |
|---|
| Team needs access to your calendar/CRM | Create an assistant with pre-configured actions |
| Shared API key for a service | Share the connection directly (if non-OAuth) |
| Personal workflow automation | Use your own connection in your assistant |
| Departmental tool access | Share via assistant with specific groups |
Summary
| Feature | OAuth | API Key / Service Account |
|---|
| User-owned | ✅ | ✅ |
| Direct sharing | ❌ | ✅ (to users, groups, workspace) |
| Share via assistant | ✅ | ✅ |
| Automatic token refresh | ✅ | N/A |
| Admin can share | ❌ | ✅ |
