Skip to main content

Feishu Destination

Nexla's bi-directional connectors allow data to flow both to and from any location, making it simple to create a FlexFlow data flow that sends data to a Feishu location.
feishu_api.png

Feishu

Create a Feishu Destination​

  1. Click the + icon on the Nexset that will be sent to the Feishu destination, and select the Send to Destination option from the menu.

  2. 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.

  3. In Nexla, Feishu destinations can be created using pre-built endpoint templates, which expedite destination setup for common Feishu endpoints. Each template is designed specifically for the corresponding Feishu API endpoint, making destination configuration easy and efficient.
    • To configure this destination using a template, follow the instructions in Configure Using a Template.

    Feishu destinations can also be configured manually, allowing you to send data to Feishu endpoints not included in the pre-built templates or apply further customizations to exactly suit your needs.
    • To configure this destination manually, follow the instructions in Configure Manually.

Configure Using a Template​

Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Feishu endpoints. Each template is designed specifically for the corresponding Feishu API endpoint, making destination setup easy and efficient.

  • To configure this destination using a template, 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:

      • {"fields":{"Name":"John Smith","Status":"Active","Score":95}}
      • 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:

      • {"records":[{"fields":{"Name":"Alice","Score":90}},{"fields":{"Name":"Bob","Score":85}}]}
      • 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:

      • {"records":["recxxxxxxxxxxxxxxxx","recyyyyyyyyyyyyyyyy"]}

    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.

Configure Manually​

Feishu destinations can 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.

API Method​

  1. To manually configure this destination, select the Advanced tab at the top of the configuration screen.

  2. Select the API method that will be used for calls to the Feishu API from the Method pulldown menu. Common methods for Feishu destinations include:

    • POST: For creating new resources (messages, records, tasks, documents, chats)
    • PUT: For full replacements (updating a chat, updating a Bitable record)
    • PATCH: For partial updates (updating a message, calendar event, task, or user)
    • DELETE: For removing resources (deleting tasks, calendar events, or Bitable records)

Data Format​

  1. Select the format in which the Nexset data will be sent to the Feishu API from the Content Format pulldown menu. Nexla will automatically convert the data to the selected format for each API call.

    The Feishu Open Platform API accepts JSON (application/json) for all write operations. Select JSON as the Content Format.

API Endpoint URL​

  1. Enter the URL of the Feishu API endpoint to which you want to send the Nexset data in the URL field. All Feishu Open Platform endpoints follow this pattern:

    • China (Feishu): https://open.feishu.cn/open-apis/{service}/{version}/{resource}
    • International (Lark): https://open.larksuite.com/open-apis/{service}/{version}/{resource}

    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} for updating a specific message).

Request Headers​

Optional

  • If Nexla should include any additional request headers in API calls to this destination, enter the headers & corresponding values as comma-separated pairs in the Request Headers field (e.g., header1:value1,header2:value2).

    You do not need to include the Authorization header — Nexla automatically adds the Authorization: Bearer {tenant_access_token} header using the configured Feishu credential.

Exclude Attributes from the Call​

Optional

  • If any record attributes in the Nexset should be omitted when sending data to this Feishu destination, select the attributes from the Exclude Attributes pulldown menu.

  • Any number of attributes can be selected for exclusion, and all excluded attributes will be shown in the field. To remove an attribute from the list, click the X icon next to the attribute name.

Record Batching​

Optional

  1. If records should be sent to this destination in batched API calls, check the box next to Would you like to batch your records together? to enable record batching.

  2. Enter the maximum number of records that should be batched together in a single API call in the Batch Size field. By default, this value is set to 100. For the Feishu Batch Create Bitable Records endpoint, the maximum batch size is 1,000 records.

  3. Select the algorithm that will be used to group records into batches from the Grouping Algorithm pulldown menu. The sample request shown in the panel on the right will be updated to reflect the current batching settings.

Response Webhook​

Optional

Nexla can automatically send the response received from the Feishu API after each call to a new Nexla webhook data source. This option allows you to keep track of the status of each API call and any additional information returned after each call — for example, capturing the message_id returned after sending a message, or the record_id returned after creating a Bitable record.

  • To enable this option, check the box next to Would you like to process the API response as a Nexla Webhook source?.

Sample Request Payload​

Sample request payloads containing a portion of the Nexset data that will be sent to the Feishu API endpoint based on the current settings are shown in the Sample Payload panel on the right. These samples can be referenced to ensure that the destination and request settings are correctly configured.

  • Click on a sample request payload to expand it and view the complete payload content.
  • Sample payloads are automatically updated with each setting change, making it easy to verify that changes achieve the desired effect.

Endpoint Testing (Manual Configuration)​

After all endpoint settings have been configured, Nexla can send a test payload to the Feishu API to ensure that the destination is configured correctly.

  1. To send a test payload, select the Test button at the top of the Sample Payload panel, and click on a listed sample payload to expand it.

  2. If any modifications to the sample payload are needed, make the necessary changes directly within the sample window.

  3. Click the Send Test Data button at the top of a sample payload to send the test payload to the Feishu API using the current settings.

Save & Activate the Destination​

  • 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.