Integrations vs. Actions

Integrations are standardized connections between Langdock and third-party tools that handle authentication and API communication. Within each integration, you can build actions that let assistants interact with specific API endpoints. Here’s how to create an integration and set up ready-to-use actions.

Setting up an Integation

In the integrations menu, click Build integration to get started.

Next, specify an integration name and upload an icon (shown in chat when using actions and in the integrations overview). Add a description to help assistants know when to use this integration. Hit Save to create it.

Authentication

Start with authentication in the Build tab. Select your authentication type and configure it following the steps below:

API Key

After selecting API Key authentication, add custom input fields in step 2 (like API key or client ID). These inputs are collected when users set up connections and can be marked as “required.”

Step 3 lets you set up a test API endpoint to validate authentication. Replace the URL parameter and add references to your input fields using data.auth.fieldId.

Use the built-in ld.request and ld.log functions for requests and logging.

Test your action and create your first connection.

OAuth 2.0

Custom integrations support OAuth 2.0 authentication.

Step 2 allows custom input fields (collected during connection setup). Client ID and Client Secret are entered in step 4, so this covers additional parameters only.

Create an OAuth client

Set up an OAuth client/App/Project in your target application and enable the required APIs. This is application-specific, which is why our interface supports custom code in step 5.

For Google Calendar, create a Google Service Account, generate a new key to get the client ID and secret, add them to Langdock in step 4, save the OAuth Redirect URL, and enable the Google Calendar API.

Change Authorization URL

Check the OAuth documentation for your service and extract the Authorization URL. Usually, changing the BASE_URL in our template is sufficient.

For Google Calendar:

return `https://accounts.google.com/o/oauth2/v2/auth?client_id=${env.CLIENT_ID}&response_type=code&scope=${data.input.scope}&access_type=offline&redirect_uri=${encodeURIComponent(data.input.redirectUrl)}&state=${data.input.state}&prompt=consent`;

Define Scopes

Define OAuth scopes required by your actions. List them comma or space-separated according to your API documentation.

For Google Calendar (space-separated):

https://www.googleapis.com/auth/calendar.events https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile

Provide Access Token & Refresh Token URL

Check your API’s OAuth docs for the Access Token URL and Refresh Token URL. Usually, updating the tokenUrl in our template works.

For Google Calendar:

const tokenUrl ='https://oauth2.googleapis.com/token';

Test Authentication Setup

Provide a test API endpoint (like /me) to verify authentication. The return value of that test request can be used inside the OAuth Client Label to influence the naming of the established connections. You can access the return value via: {{data.input}}

For Google Calendar: Google Sheets - {{data.input.useremail.value}}

Test by adding a connection and verifying the authorization flow works.

For Google Calendar, we test with:

url: 'https://people.googleapis.com/v1/people/me?personFields=names,emailAddresses'

Public APIs

Choose None for publicly available APIs without authentication.

Accessing input fields

Use data.input.{inputFieldId} for input field values and data.auth.{authenticationFieldId} for authentication field values from the user’s current connection.

Built-in functions for custom code sections

Use our Integration Assistant to help set up your integration functions.

Basic functions

The custom client library ld contains the core functionality needed for implementing authentication flows.

ld.request() creates a web request using the format specified by the passed object and returns the response. The parameters must be valid JSON objects since JSON.stringify() is called internally. For complex JSON objects, you’ll need to apply JSON.parse() first.

ld.log() outputs the passed values to the Logs field, which appears below the Test Action button after running an action.

Example usage from the Google Calendar integration:

const options = {
  method: 'GET',
  url: `https://www.googleapis.com/calendar/v3/calendars/${data.input.calendarId}/events/${data.input.eventId}`,
  headers: {
    'Authorization': 'Bearer ' + data.auth.access_token,
    'Accept': 'application/json',
  },
};

const response = await ld.request(options);

return response.json;

JSON

Both JSON.stringify() (converting a JavaScript JSON object into a string) and JSON.parse() (converting a string into a JavaScript JSON object) are available in custom code blocks.

The parameters passed to the ld.request() function must be valid JSON objects since JSON.stringify() is called internally. For complex JSON structures, you’ll need to apply JSON.parse() beforehand to ensure proper formatting.

Example usage from the HubSpot integration:

const properties = data.input.properties
  ? JSON.parse(data.input.properties)
  : {};

const options = {
  method: 'PATCH',
  url: `https://api.hubapi.com/crm/v3/objects/companies/${data.input.companyId}`,
  headers: {
    'Authorization': 'Bearer ' + data.auth.access_token,
    'Content-Type': 'application/json',
  },
  body: {
    properties: properties,
  },
};

Base 64

Since some OAuth clients require Base64-encoded client credentials for Basic authentication, we’ve built a helper function for this.

btoa() encodes a string to Base64, while atob() decodes a Base64 string back to plain text.

Example usage:

const auth = btoa(`${env.CLIENT_ID}:${env.CLIENT_SECRET}`);

Usability Recommendations

To make actions more usable within assistants, we recommend thinking about these aspects:

ID Handling

Most API calls require specific internal IDs. The challenge is that assistants can’t guess these IDs, which creates a poor user experience when calling actions like “get specific contact in HubSpot” or “add event to specific calendar in Google Calendar.”

The solution: Create helper actions that retrieve and return these IDs to the assistant first. For example, our Get deal context function for HubSpot uses GET endpoints to gather internal IDs for available pipelines and stages. This enables assistants to use actions like Create deal or Update deal much more effectively since they now have the required context.

Native Actions

Native actions allow you to natively search and download files that aren’t stored locally on a user’s device. We’ve already built native actions for SharePoint, OneDrive, Google Drive, and Confluence. You can access these via the Select files button to search and attach files directly to Chat or Assistant Knowledge.

Attach files to the chat using native integrations.

Attach files to the Assistant knowledge by using a native integration.

Building native actions for other tools enables you to search and download files from those platforms in the same way.

Setting up a Native Action

To set up a native action, begin building your integration as usual. Add another action, and in Step 1 under Advanced, select either “Search files” or “Download file” as the action type.

Afterwards, you build the action as any other action, but your function needs to return a specific object structure. This ensures compatibility and enables assistants to handle files and search results correctly.

Required Output Format

Depending on the action you select, your function must return a specific object structure. This ensures compatibility and enables assistants to handle files and search results correctly.

Search files: When building a native search integration, your function must return an array of objects matching the following schema:

{
  url: string,
  documentId: string,
  title: string,
  author?: {
    id: string,
    name: string,
    imgUrl?: string,
  },
  mimeType: string,
  lastSeenByUser: Date,
  createdDate: Date,
  lastModifiedByAnyone: Date,
  lastModifiedByUserId?: {
    id?: string,
    name?: string,
    lastModifiedByUserIdDate: Date,
  },
  parent?: {
    id: string,
    title?: string,
    url?: string,
    type?: string,
    driveId?: string,
    siteId?: string,
    listId?: string,
    listItemId?: string,
  }
}

The title and mimeType will be displayed in the UI for all search results.

Please also check out a detailed description for each parameter:

Below you can find an example implementation for the native SharePoint Search files action.

Download file
For native download actions, return an object in the following format:

{
  data: response.data,
  fileName: string,
  mimeType: string,
  buffer: response.buffer, // Conditional
  url: string,
  lastModified: Date,
  text: string // Conditional
}

The fileName and mimeType will be displayed in the UI for all search results.

Please also check out a detailed description for each parameter:

Below you can find an example implementation for the native SharePoint Download file action.