Feishu (飞书) is an enterprise collaboration platform by ByteDance that unifies messaging, video conferencing, cloud documents, multi-dimensional spreadsheets (Bitable), calendar, tasks, and approval workflows in one workspace. Organizations in China connect via open.feishu.cn, while the international version, Lark, is at open.larksuite.com. Its Open Platform exposes 2,500+ server-side APIs.
Power end-to-end data operations for your Feishu API with Nexla. Our bi-directional Feishu connector is purpose-built for Feishu, making it simple to ingest data, sync it across systems, and deliver it anywhere — all with no coding required. Nexla turns API-sourced data into ready-to-use, reusable data products and makes it easy to send data to Feishu or any other destination. With comprehensive monitoring, lineage tracking, and access controls, Nexla keeps your Feishu workflows fast, secure, and fully governed.
Features
Type: API
SourceDestination
Seamless API Integration: Connect to any endpoint as source or destination without coding, with automatic data product creation
Visual Composition & Chaining: Build complex integrations using visual templates, chain API calls, and compose workflows with data validation and filtering
API Proxy: Expose curated slices of your data securely with a secure and customizable API proxy that validates and transforms data on the fly
Request optimization with intelligent batching, retry, and caching to minimize API calls and costs
Nexla connects to Feishu (China region) and Lark (international region) using a custom app created in the Feishu Open Platform Developer Console. The app authenticates via its App ID and App Secret, which Nexla exchanges for a short-lived tenant_access_token (valid for approximately 2 hours, automatically refreshed) that is sent as a Bearer token on every API call.
Feishu and Lark are the same underlying platform but operate on separate, isolated infrastructure. Apps and tokens created in one region cannot be used in the other. Before creating your app, confirm which base URL applies to your organization:
Click Create App, then select Custom App (also labeled "Enterprise Custom App" in some console versions).
Enter an App Name and optional App Description that clearly identifies this as the integration used by Nexla (for example, "Nexla Data Integration"). Click Confirm.
On the app's main page, navigate to Credentials & Basic Info in the left sidebar. Your App ID and App Secret are displayed in the Credentials section. Copy both values—they will be entered into Nexla in the steps below.
Protect Your App Secret
The App Secret grants full programmatic access to your Feishu/Lark tenant using this app's permissions. Treat it like a password: do not commit it to source control or share it publicly.
Nexla requires specific permission scopes depending on which Feishu APIs your data flows will use. Without the correct scopes, API calls will return authorization errors.
In the Developer Console, navigate to Permission Management (or Permissions & Scopes) in the left sidebar.
Search for and enable the scopes that correspond to the data your flows will access. Common scopes include:
Bitable: bitable:app (read/write Bitable records and fields)
Custom apps must be enabled before their credentials are active:
Navigate to App Release (or Version Management & Release) in the Developer Console sidebar.
Create a version and click Apply for Online Release, or for internal enterprise apps, use Enable App to make it available to your tenant without a formal release.
For apps used solely for server-to-server API calls (such as Nexla integrations), a full public release is not required. Enabling the app for internal use within your tenant is sufficient.
Feishu/Lark custom-app auth. Exchanges app_id and app_secret for a tenant_access_token (TTL ~2h, auto-refreshed) sent as 'Authorization: Bearer <token>' on every API call.
Field
Required
Secret
Description
Base URL
Yes
No
Region-specific Feishu Open Platform base URL. Use https://open.feishu.cn for China (Feishu) or https://open.larksuite.com for Lark. Apps and tokens are NOT interchangeable across regions. Allowed values: China (Feishu); International (Lark)
App ID
Yes
No
The App ID of your Feishu/Lark custom app, obtained from the Developer Console (Credentials & Basic Info).
App Secret
Yes
Yes
The App Secret of your Feishu/Lark custom app, obtained from the Developer Console. Used together with the App ID to obtain a tenant_access_token.
After selecting the data source/destination type, click the Add Credential tile to open the Add New Credential overlay.
Enter a name for the credential in the Credential Name field and a short, meaningful description in the Credential Description field.
Select the Base URL that corresponds to your organization's region from the pulldown menu:
China (Feishu) — https://open.feishu.cn (default)
International (Lark) — https://open.larksuite.com
This setting determines which Feishu/Lark API infrastructure Nexla connects to. Apps and tokens are not interchangeable between regions, so the Base URL must match the region where your custom app was created.
Enter the App ID of your Feishu/Lark custom app in the App ID field. The App ID is a string beginning with cli_ that uniquely identifies your application. It can be found on the Credentials & Basic Info page of your app in the Developer Console.
Enter the App Secret of your Feishu/Lark custom app in the App Secret field. The App Secret is found alongside the App ID on the Credentials & Basic Info page in the Developer Console.
warning
The App Secret is displayed only once when the app is created. If you have lost it, you can regenerate it from the Developer Console under Credentials & Basic Info — but regenerating invalidates the previous secret and will break any existing integrations using the old value.
Click the Save button at the bottom of the overlay. The newly added credential will now appear in a tile on the Authenticate screen during data source/destination creation.
To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Select the Feishu connector tile, then select the credential that will be used to connect to the Feishu instance, and click Next; or, create a new Feishu credential for use in this flow.
Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common Feishu endpoints. Select the endpoint from which this source will fetch data from the Endpoint pulldown menu. Available endpoint templates are listed in the expandable boxes below.
Search Bitable Records
Searches and lists records in a Feishu Bitable table using the POST /records/search API. This endpoint replaces the deprecated GET /records endpoint and supports filtering, sorting, field selection, and view scoping. It returns up to 500 records per page using cursor-based pagination. Use this endpoint to extract structured data from any Bitable (multi-dimensional spreadsheet) table for analytics, reporting, or downstream processing.
Enter the App Token that identifies the Bitable application. The app token is the unique identifier for the Base (multi-dimensional table) application and can be found in the URL when viewing the Bitable in your browser — it appears after /base/ in the URL (for example, bascnxxxxxxxxxxxxxxxxxx). This field is required.
Enter the Table ID of the specific table within the Bitable application. The table ID identifies which sheet or table within the Base to query. It appears in the URL after the app token when a table is selected, or you can retrieve it using the Feishu API. This field is required.
Optionally, enter a View ID to scope the search to a specific view within the table. Views in Bitable are saved filter/sort configurations. Leave blank to search across all records regardless of view. The view ID can be found in the URL when a specific view is selected in the Bitable UI.
Optionally, enter a Field Names (JSON array) value to limit the fields (columns) returned. Enter a JSON array of field names to return — for example, ["Name","Status","Due Date"]. Use an empty array [] to return all fields.
Optionally, enter a Filter (JSON object) to narrow results to records that match specific conditions. Enter a JSON filter object using Bitable filter syntax — for example:
{"conjunction":"and","conditions":[{"field_name":"Status","operator":"is","value":["Done"]}]} returns only records where the Status field equals "Done".
Optionally, enter a Sort (JSON array) to specify the sort order for returned records. Enter a JSON array of sort objects — for example, [{"field_name":"Created","desc":true}] sorts records by the Created field in descending order. Use an empty array [] for no sorting.
Optionally, select a User ID Type to control how user identifiers appear in person-type fields. Options are:
open_id (default) — A user ID that is unique to this app. Recommended for most integrations.
union_id — A user ID that is consistent across all apps within the same vendor account.
user_id — The enterprise-assigned user ID. Requires the contact:user.employee_id:readonly scope.
This endpoint uses cursor-based pagination and fetches up to 500 records per page. Nexla handles pagination automatically. For very large tables, consider using filters or view IDs to limit the result set and improve performance.
List Bitable Fields
Returns all field (column) definitions for a Bitable table, including field names, types, and configuration. Use this endpoint to discover the schema of a Bitable table before building a data source, or to track schema changes over time.
Enter the App Token that identifies the Bitable application. This is the same token used in the Search Bitable Records endpoint — found in the URL after /base/ when viewing the Bitable in your browser. This field is required.
Enter the Table ID of the table whose fields you want to list. This field is required.
This endpoint returns up to 100 fields per page with cursor-based pagination. Nexla handles pagination automatically. The response includes each field's name, type, property configuration, and whether it is a primary field.
List Approval Instances
Retrieves a batch of approval instance codes for a specific approval workflow, sorted by creation time. Use this endpoint to extract approval workflow data — such as submitted requests, their statuses, and associated metadata — for reporting or downstream processing.
Enter the Approval Code that identifies the approval definition (workflow) to query. The approval code is a unique string that identifies a specific approval process in Feishu. You can find it in the Feishu Admin Console under the approval management section, or via the Feishu Approval API. This field is required.
Enter the Start Time (ms epoch) as the lower bound of the time window in milliseconds since Unix epoch. This field is required. The total window between start and end time must be no more than 10 hours.
Enter the End Time (ms epoch) as the upper bound of the time window in milliseconds since Unix epoch. This field is required. The total window between start and end time must be no more than 10 hours.
Optionally, enter a User ID to filter results to instances submitted by a specific user. When provided, only approval instances initiated by that user within the time window are returned.
This endpoint returns approval instance codes (not full instance details). To retrieve detailed information for a specific approval instance, use the Feishu Approval API's "Get Approval Instance" endpoint with each returned instance code. The time window is strictly limited to 10 hours per request; use incremental scheduling in Nexla to cover longer time periods.
Get User
Retrieves the full profile of a single Feishu/Lark user by their user ID, including name, department membership, email, mobile number, and account status. Use this endpoint to look up individual user records for directory synchronization, user provisioning, or access management workflows.
Enter the User ID of the user to retrieve. The format of this ID depends on the User ID Type selected below. This field is required.
Select the User ID Type that corresponds to the User ID value you provided:
open_id (default) — The app-specific user ID (begins with ou_).
union_id — The cross-app user ID consistent across all apps in the same vendor account.
user_id — The enterprise-assigned employee ID.
Select the Department ID Type to control how department IDs appear in the returned user profile:
open_department_id (default) — The app-specific department ID.
department_id — The enterprise-assigned department ID.
This endpoint returns a single user record (not a paginated list). To retrieve users across a department, use the List Users by Department endpoint instead. The response includes the user's name, departments, email, mobile, job title, status, and other profile fields.
List Users by Department
Lists all users who are direct members of a specified department, with cursor-based pagination. Use this endpoint for HR data exports, organizational directory synchronization, or when you need a complete roster of users in a specific department.
Enter the Department ID of the department whose direct members will be listed. This field is required. The format of the ID depends on the Department ID Type selected below. The root department can be queried using 0 as the department ID.
Select the User ID Type to control how user identifiers appear in the response:
open_id (default) — The app-specific user ID.
union_id — The cross-app user ID.
user_id — The enterprise-assigned employee ID.
Select the Department ID Type that matches the format of the Department ID you entered:
open_department_id (default) — The app-specific department ID.
department_id — The enterprise-assigned department ID.
This endpoint lists only direct members of the specified department — it does not include members of sub-departments. Nexla handles cursor-based pagination automatically, returning up to 50 users per page. To list users in sub-departments, issue separate requests for each sub-department's ID.
Get Message
Retrieves the content and metadata of a single Feishu message by its message ID. Use this endpoint to fetch specific messages for archival, compliance logging, or content analysis workflows.
Enter the Message ID of the message to retrieve. Message IDs in Feishu begin with om_ and can be obtained from Feishu message event webhooks, the List Chat Messages endpoint, or the Feishu IM API. This field is required.
The response includes the message body, sender information, creation timestamp, and message type. Rich message types (cards, files, images) include additional nested content fields. For listing multiple messages in a chat, use the List Chat Messages endpoint instead.
List Chat Messages
Lists messages in a Feishu group chat within an optional time range, using cursor-based pagination. Use this endpoint to export conversation history for archival, compliance, sentiment analysis, or business intelligence purposes.
Enter the Chat ID of the group chat whose messages will be listed. Chat IDs in Feishu begin with oc_ and can be found in the chat URL or via the Feishu IM API's list chats endpoint. This field is required.
Optionally, enter a Start Time (seconds epoch) to filter messages created at or after this timestamp. Enter a Unix timestamp in seconds (not milliseconds). Leave blank to retrieve messages from the beginning of the chat history.
Optionally, enter an End Time (seconds epoch) to filter messages created at or before this timestamp. Enter a Unix timestamp in seconds. Leave blank to retrieve messages up to the current time.
Select the Sort Type for the returned messages:
ByCreateTimeDesc (default) — Most recent messages are returned first.
ByCreateTimeAsc — Oldest messages are returned first. This is recommended for incremental exports where you want to process messages in chronological order.
This endpoint returns up to 50 messages per page using cursor-based pagination; Nexla handles pagination automatically. The bot (custom app) must be a member of the target chat to access its messages. If the app is not a chat member, the API returns an authorization error.
Get Document
Retrieves the metadata of a Feishu Docx document, including its title, current revision number, and owner information. Use this endpoint to track document inventory, monitor revisions, or build document management workflows.
Enter the Document ID of the Docx document to retrieve. The document ID can be found in the document's URL when it is open in the Feishu client — it appears as the last path segment before any query parameters (for example, doxcnxxxxxxxxxxxxxxxxxx). This field is required.
This endpoint returns document metadata only — it does not return the document's content or body text. To read document content, use the Feishu Docs API's block-level endpoints. The custom app must have the document shared with it or have the appropriate Drive permission scope to access the document.
Get Drive File Statistics
Retrieves view counts, comment counts, and other usage statistics for a file stored in Feishu Drive, identified by its file token. Use this endpoint to track document engagement, measure content popularity, or build content analytics dashboards.
Enter the File Token of the Drive file whose statistics you want to retrieve. The file token is a unique identifier for any file in Feishu Drive and can be found in the file's sharing URL or via the Feishu Drive API's file list endpoints. This field is required.
The response includes view count, comment count, and like count (where available). Statistics are aggregated and may not reflect real-time counts. The custom app must have at least read access to the file in Drive to retrieve its statistics.
Once the selected endpoint template has been configured, click the Test button to the right of the endpoint selection menu to retrieve a sample of the data that will be fetched. Sample data will be displayed in the Endpoint Test Result panel on the right, allowing you to verify that the source is configured correctly before saving.
Feishu data sources can also be manually configured to ingest data from any valid Feishu Open Platform API endpoint, including endpoints not covered by the pre-built templates, chained API calls, or custom request parameters. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, endpoint URL, date/time and lookup macros, path to data, metadata, and request headers.
Feishu Open Platform endpoints follow the pattern https://open.feishu.cn/open-apis/{service}/{version}/{resource} (or the open.larksuite.com equivalent for Lark) — for example, https://open.feishu.cn/open-apis/bitable/v1/apps/{app_token}/tables. The complete server API reference, including required parameters and example responses, is available at open.feishu.cn/document/server-docs/api-call-guide/server-api-list.
Feishu API responses consistently wrap results in a nested data object — common paths to data include $.data.items[*] for most list endpoints, $.data.records[*] for some Bitable endpoints, and $.data.user for single-user responses. To preserve page-level context (such as data.page_token or data.has_more) alongside each record, set a metadata path to capture these fields.
Date/time macros are particularly useful for the List Approval Instances endpoint (which requires start_time/end_time in milliseconds epoch, with a maximum 10-hour window per request) and the List Chat Messages endpoint (which accepts start_time/end_time in seconds epoch). You do not need to add an Authorization request header — Nexla automatically adds the Authorization: Bearer {tenant_access_token} header using the credentials configured for this connector.
Once all of the relevant settings have been configured, click the Create button in the upper right corner of the screen to save and create the new Feishu data source. Nexla will now begin ingesting data from the configured endpoint and will organize any data that it finds into one or more Nexsets.
Click the + icon on the Nexset that will be sent to the Feishu destination, and select the Send to Destination option from the menu. Select the Feishu connector from the list of available destination connectors, then select the credential that will be used to connect to the Feishu organization, and click Next; or, create a new Feishu credential for use in this flow.
Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Feishu endpoints. Select the endpoint to which data will be sent from the Endpoint pulldown menu. Then, click on the template in the list below to expand it, and follow the instructions to configure additional endpoint settings.
Send Message
Sends a message to a Feishu user, group chat, or thread. Use this endpoint to deliver notifications, alerts, workflow updates, or automated reports directly into Feishu conversations. The message body supports multiple content types including plain text, rich text (post), interactive cards, images, and files.
Select the Receive ID Type to specify what kind of identifier is used in the receive_id field of your message body:
open_id (default) — Send to a specific user identified by their app-specific open ID (begins with ou_).
user_id — Send to a user identified by their enterprise employee ID.
union_id — Send to a user identified by their cross-app union ID.
email — Send to a user identified by their email address registered in Feishu.
chat_id — Send to a group chat identified by its chat ID (begins with oc_).
Structure the Nexset data to produce a valid Feishu message body. The JSON body sent to the API must include the following fields:
receive_id — The ID of the recipient (format must match the Receive ID Type selected above).
msg_type — The message content type. Common values: text for plain text, post for rich text, interactive for card messages.
content — A JSON string containing the message content appropriate for the selected msg_type. For example, for a text message: {"text":"Hello from Nexla!"}.
The Feishu Send Message API requires the receive_id_type query parameter to match the actual type of the receive_id value in the body — mismatches return a 404 error. The custom app must have the im:message:send_as_bot permission scope enabled. For complete message content format documentation, see the Feishu Send Message API reference.
Create Chat
Creates a new Feishu group chat. Use this endpoint to programmatically provision group chats for projects, teams, or automated workflows — for example, creating a dedicated chat for each new customer account or support ticket.
Structure the Nexset data to produce a valid request body. Key fields for the Create Chat API include:
name — The display name of the new group chat.
description — An optional description for the group chat.
owner_id — The user ID of the chat owner. If omitted, the app bot is set as the owner.
user_id_list — An array of user IDs to invite as initial members.
chat_mode — The chat mode: group for a standard group chat, or topic for a topic-based chat.
The custom app must have the im:chat permission scope to create group chats. The API returns the newly created chat's chat_id in the response. For the full list of request body fields, see the Feishu Create Chat API reference.
Add Chat Members
Adds one or more members to an existing Feishu group chat. Use this endpoint to automate group membership management — for example, automatically adding new employees to relevant team chats, or adding all stakeholders to a project chat when a project is created.
Enter the Chat ID of the group chat to which members will be added. The chat ID begins with oc_ and can be found in the chat URL or via the Feishu IM API. This field is required.
Structure the Nexset data to produce a valid request body. The Add Chat Members API body must include:
id_list — An array of user IDs to add to the chat.
member_id_type — The type of IDs in id_list: open_id, user_id, or union_id.
The custom app must be a member of the chat (or the chat owner) to add new members. The app must also have the im:chat.member:write permission scope. For more details, see the Feishu Add Chat Members API reference.
Update Chat
Updates settings for an existing Feishu group chat, such as its name, description, avatar, or owner. Use this endpoint to keep group chat metadata synchronized with external systems — for example, renaming a chat when a project name changes.
Enter the Chat ID of the group chat to update. This field is required.
Structure the Nexset data to produce a valid request body. Fields that can be updated include:
name — The new display name for the group chat.
description — The new description for the group chat.
owner_id — The user ID of the new chat owner.
add_member_permission — Who can add members: all_members or only_owner.
This endpoint uses PUT semantics — supply all fields you want to retain, as omitted optional fields may be reset to defaults. The custom app must be the chat owner or have admin privileges to update chat settings.
Update Message
Edits a previously sent Feishu message by its message ID. Use this endpoint to update message content — for example, updating a status notification message as a workflow progresses, or correcting automated alerts.
Enter the Message ID of the message to edit. The message ID begins with om_. This field is required.
Structure the Nexset data to produce a valid request body. The body must include:
msg_type — The message content type (must match the original message type).
content — A JSON string containing the new message content.
Only the app or bot that originally sent the message can edit it. The msg_type must match the original message type — you cannot change a text message to a card message via an update. For more details, see the Feishu Update Message API reference.
Create Calendar Event
Creates a new event on a specified Feishu calendar. Use this endpoint to automate event scheduling — for example, creating onboarding meetings when a new employee record is processed, or adding project milestones to a shared calendar automatically.
Enter the Calendar ID of the calendar on which the event will be created. The primary personal calendar uses primary as the calendar ID. Shared or subscription calendar IDs can be retrieved from the Feishu Calendar API. This field is required.
Structure the Nexset data to produce a valid event body. Key fields include:
summary — The event title.
description — An optional description for the event.
start_time — An object with timestamp (Unix epoch in seconds as a string) and optional timezone (e.g., Asia/Shanghai).
end_time — An object with the same structure as start_time.
attendees — An optional array of attendee objects, each with a type (user) and user_id.
All timestamps in the Feishu Calendar API are provided as strings containing Unix epoch values in seconds (not milliseconds). The custom app must have the calendar:calendar permission scope and must be a member of the target calendar. For the complete event body schema, see the Feishu Create Calendar Event API reference.
Update Calendar Event
Updates an existing Feishu calendar event using PATCH semantics — only the fields supplied in the request body are modified. Use this endpoint to keep calendar events synchronized with external data sources, such as updating meeting times when a scheduling tool changes them.
Enter the Calendar ID containing the event to update. This field is required.
Enter the Event ID of the event to update. Event IDs can be obtained from the response of the Create Calendar Event endpoint or from the Feishu Calendar API's event list endpoints. This field is required.
Structure the Nexset data to produce a valid PATCH body containing only the fields to be updated (for example, summary, start_time, end_time, or description).
Because this endpoint uses PATCH semantics, only the fields you include in the request body are changed. Fields not included retain their existing values. For the complete list of updatable fields, see the Feishu Update Calendar Event API reference.
Delete Calendar Event
Deletes an existing Feishu calendar event. Use this endpoint to remove calendar events when corresponding records are deleted or cancelled in an external system — for example, removing interview events when a candidate withdraws from a hiring process.
Enter the Calendar ID containing the event to delete. This field is required.
Enter the Event ID of the event to delete. This field is required.
This action is irreversible — deleted calendar events cannot be recovered via the API. The custom app must have write access to the calendar and the calendar:calendar permission scope. For more details, see the Feishu Delete Calendar Event API reference.
Create Bitable Record
Creates a single new record (row) in a Feishu Bitable table. Use this endpoint to write data from external systems into Bitable for reporting, tracking, or workflow management — for example, logging CRM opportunities, support tickets, or survey responses into a Bitable table.
Enter the App Token of the Bitable application. The app token is found in the URL when viewing the Base — it appears after /base/. This field is required.
Enter the Table ID of the specific table within the Bitable application where the record will be created. This field is required.
Structure the Nexset data to produce a valid request body. The body must include a fields object containing the field names and their values — for example:
Field names must exactly match the column names in the Bitable table (case-sensitive).
Field value formats depend on the field type — text fields accept strings, number fields accept numbers, date fields accept Unix epoch timestamps in milliseconds.
The custom app must have the bitable:app permission scope and write access to the Base. For the complete field value format reference by field type, see the Feishu Create Bitable Record API reference.
Batch Create Bitable Records
Creates up to 1,000 records in a single API request to a Feishu Bitable table. Use this endpoint for high-volume data ingestion into Bitable — for example, bulk-loading daily transaction data, migrating records from another system, or writing large result sets from analytics pipelines.
Enter the App Token of the Bitable application. This field is required.
Enter the Table ID of the table where records will be created. This field is required.
Structure the Nexset data to produce a valid batch request body. The body must include a records array where each element contains a fields object — for example:
A maximum of 1,000 records can be submitted per request. Nexla's batch mode handles splitting larger datasets into compliant batches automatically when batch mode is enabled.
This endpoint is the recommended approach for writing multiple records to Bitable efficiently. For the complete API reference including field value formats, see the Feishu Batch Create Bitable Records API reference.
Update Bitable Record
Updates an existing record in a Feishu Bitable table by its record ID. Use this endpoint to keep Bitable data synchronized with external systems — for example, updating the status of a record when a task is completed, or refreshing metric values in a Bitable dashboard.
Enter the App Token of the Bitable application. This field is required.
Enter the Table ID of the table containing the record to update. This field is required.
Enter the Record ID of the specific row to update. Record IDs begin with rec and can be obtained from the Search Bitable Records endpoint or from previous Create Bitable Record responses. This field is required.
Structure the Nexset data to produce a valid request body. The body must include a fields object with the fields to update and their new values. Only the fields included in the body are modified.
This endpoint uses PUT semantics for the record — all fields in the fields object are overwritten with the new values. Fields not included in the body retain their existing values. For the complete API reference, see the Feishu Update Bitable Record API reference.
Batch Delete Bitable Records
Deletes multiple records from a Feishu Bitable table in a single request. Use this endpoint to remove outdated or invalid records in bulk — for example, purging expired entries, removing test data, or synchronizing deletions from an external system.
Enter the App Token of the Bitable application. This field is required.
Enter the Table ID of the table from which records will be deleted. This field is required.
Structure the Nexset data to produce a valid request body. The body must include a records array of record IDs to delete — for example:
This action is irreversible — deleted Bitable records cannot be recovered via the API. Before running bulk deletions in production, verify the record IDs using the Search Bitable Records source endpoint. For the complete API reference, see the Feishu Batch Delete Bitable Records API reference.
Create Task
Creates a new task in Feishu Task v2. Use this endpoint to automate task creation — for example, generating follow-up tasks from CRM data, creating onboarding checklist items for new employees, or creating action items from meeting notes.
Structure the Nexset data to produce a valid request body. Key fields for the Create Task API include:
summary — The task title (required).
description — An optional plain-text description of the task.
due — An optional due date object with a timestamp field (Unix epoch in milliseconds as a string).
members — An optional array of member objects. Each member includes an id (user open_id) and role (assignee or follower).
origin — An optional origin object describing the source system, used to link tasks back to external records.
The custom app must have the task:task permission scope. Tasks created by the app are owned by the app bot by default. For the complete request body schema and field types, see the Feishu Create Task API reference.
Update Task
Updates an existing Feishu task using PATCH semantics — only the supplied fields are modified. Use this endpoint to keep task data synchronized with external systems, such as updating task status, due dates, or assignees when an external workflow state changes.
Enter the Task ID of the task to update. Task IDs can be obtained from the Create Task response or from the Feishu Task API's list tasks endpoints. This field is required.
Structure the Nexset data to produce a valid PATCH body. Common fields to update include:
summary — Updated task title.
description — Updated task description.
due — Updated due date object.
completed_at — Set to a Unix epoch timestamp string to mark the task as complete, or 0 to reopen it.
Because this endpoint uses PATCH semantics, only the fields you include in the request body are changed. For the complete list of updatable fields and their formats, see the Feishu Update Task API reference.
Delete Task
Deletes a task from Feishu Task v2 by its task ID. Use this endpoint to remove tasks when corresponding records are cancelled or removed in an external system.
Enter the Task ID of the task to delete. This field is required.
This action is irreversible. The custom app must have the task:task permission scope and must be the task creator or have admin access to delete the task. For more details, see the Feishu Delete Task API reference.
Create Document
Creates a new Feishu Docx document in a specified Drive folder. Use this endpoint to automate document generation — for example, creating templated meeting notes, generating reports, or provisioning onboarding documents.
Structure the Nexset data to produce a valid request body. Key fields include:
folder_token — The Drive folder token where the document will be created. Leave blank to create the document in the app bot's root My Drive folder.
title — The initial title of the new document.
This endpoint creates a blank document with the specified title. To add content to the document after creation, use the Feishu Docx API's block-level write endpoints with the returned document_id. The custom app must have the docx:document permission scope and write access to the target folder. For the complete API reference, see the Feishu Create Document API reference.
Create Approval Instance
Submits a new approval instance against an existing approval definition (workflow). Use this endpoint to trigger approval processes from external data — for example, automatically initiating a purchase approval when an order exceeds a threshold, or submitting leave requests generated from an HR system.
Structure the Nexset data to produce a valid request body. Required fields include:
approval_code — The code of the approval definition to use (identifies the workflow template).
user_id — The ID of the user submitting the approval request.
form — A JSON string containing the form field values for this approval instance, matching the form schema defined in the approval definition.
department_id — Optional. The department ID of the submitter, required if the approval definition is department-scoped.
The approval form fields must match the schema defined in the approval definition in Feishu Admin Console. The custom app must have the approval:approval permission scope. For the form field format and complete API reference, see the Feishu Create Approval Instance API reference.
Approve Approval Task
Approves (agrees to) a pending approval task programmatically. Use this endpoint to automate approval decisions in workflows where automated business rules determine the outcome — for example, auto-approving low-value purchase requests that meet predefined criteria.
Structure the Nexset data to produce a valid request body. All four fields are required:
approval_code — The approval definition code for the workflow.
instance_code — The code of the specific approval instance being approved.
user_id — The ID of the approver user (must be assigned to this approval task).
task_id — The specific task ID within the approval instance to approve.
The user specified in user_id must be an assigned approver for the task. Automated approval actions should be used carefully and only when business rules unambiguously determine the appropriate decision. For the complete API reference, see the Feishu Approve Approval Task API reference.
Create User
Creates a new user in the Feishu/Lark organizational directory. Use this endpoint to automate employee provisioning — for example, creating Feishu accounts when new employees are added to an HR system.
Structure the Nexset data to produce a valid request body. Required and commonly used fields include:
name — The user's display name (required).
mobile — The user's mobile phone number (required if email is not provided).
email — The user's email address (required if mobile is not provided).
department_ids — An array of department IDs the user will belong to (required).
employee_no — Optional employee number.
job_title — Optional job title.
Creating users requires the contact:user permission scope with write access. The mobile number must include the country code (e.g., +8613800138000 for a China number). For the complete list of required and optional fields, see the Feishu Create User API reference.
Update User
Updates an existing user's profile in the Feishu/Lark directory using PATCH semantics. Use this endpoint to keep Feishu user profiles synchronized with an authoritative HR or identity system — for example, updating job titles, department assignments, or contact information when they change.
Enter the User ID of the user to update. This field is required. The format of the ID must match the user_id_type accepted by the API (default is open_id).
Structure the Nexset data to produce a valid PATCH body containing only the fields to be updated (for example, name, job_title, department_ids, or mobile). Fields not included retain their existing values.
Updating users requires the contact:user permission scope with write access. Updating a user's department assignment (department_ids) may trigger organizational change notifications within Feishu. For the complete list of updatable fields, see the Feishu Update User API reference.
Feishu destinations can also be manually configured to send data to any valid Feishu Open Platform API endpoint. Using manual configuration, you can also configure Nexla to automatically send the response received from the Feishu API after each call to a new Nexla webhook data source. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, data format, endpoint URL, request headers, attribute exclusions, record batching, and response webhooks.
The Feishu Open Platform API accepts JSON (application/json) for all write operations — select JSON as the Content Format. Endpoint URLs follow the pattern https://open.feishu.cn/open-apis/{service}/{version}/{resource} (or the open.larksuite.com equivalent for Lark); for update or delete operations, append the resource ID at the end of the URL (for example, https://open.feishu.cn/open-apis/im/v1/messages/{message_id}). You do not need to add an Authorization request header — Nexla automatically adds the Authorization: Bearer {tenant_access_token} header using the configured Feishu credential.
For the Batch Create Bitable Records endpoint, the maximum batch size is 1,000 records per request. Enabling the response webhook option is useful for capturing values returned after a call, such as the message_id returned after sending a message or the record_id returned after creating a Bitable record.
Once all endpoint settings have been configured, click the Done button in the upper right corner of the screen to save and create the destination. To begin sending data to the configured Feishu endpoint, open the destination resource menu, and select Activate.
The Nexset data will not be sent to the Feishu endpoint until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.
