Feishu

Use the Feishu source to replicate Approval, Bitable/Base, Attendance, Contact, and EHR employee-roster data from a customer-managed Feishu tenant into Daspire.

Feishu and Lark appear as separate source entries in Daspire because customers manage them in different Open Platform portals and tenants. They share the same connector implementation under the hood.

Supported modules

Module	Status	Output
Approval	Supported	Raw approval instance payloads, approval instance base records, approval field key/value rows, task details, and timeline details
Bitable/Base	Supported	Bitable record metadata plus raw fields JSON
Attendance	Supported	Check-in flow records for all visible users by default, with optional employee ID filters
Contact	Supported	Users under the root department by default, with optional department filters

EHR employee roster (Native)

The opt-in EHR employee roster module exposes ehr_employees. Use a customer-owned Feishu custom app with tenant administrator approval and the Read employee roster (ehr:employee:readonly) permission. The endpoint uses an app's tenant access token; a user access token or Contact permission alone is insufficient. Source check probes the EHR endpoint so missing permission fails before a sync is scheduled.

Select ehr in Modules. Approval codes are needed only when Approval is also selected. Existing approval sources retain their selected streams. This module is implemented in the Native Feishu image; the historical Airbyte Feishu/Lark images do not gain roster support from this release.

The source reads every page of GET /open-apis/ehr/v1/employees with view=full and user_id_type=user_id, without status, employee type or date filters. All statuses returned by the app's authorized scope are retained, including leavers. An empty result can mean an empty permission scope and must be checked against HR's expected population before accepting the data.

Output	Meaning
user_id	Stable tenant employee key when assigned; pending/canceled onboarding rows may have null
employee_no	HR employee number; do not substitute it for the stable key
name, en_name	HR names
department_id, manager, job, job_level	Organization and role references as returned by EHR
status, employee_type	Original numeric status and type; HR owns the business mapping
hire_date, conversion_date, last_day	Original HR dates
system_fields, custom_fields	Original standard and custom fields for downstream mapping
extracted_at	UTC extraction time shared by all rows in that scan

Refresh and downstream use

Use full refresh, initially daily through Daspire's existing schedule. EHR's start_time/end_time constrain hire dates, not record modification times, so using them as incremental cursors would miss department and termination changes. Every subsequent refresh scans existing employees again. No change-data-capture or deletion event is implied by this API.

Publish a complete successful snapshot to the reporting model. user_id is a stable join key for employees who have one. Pending and canceled onboarding rows can have null user_id; they are retained without an invented identity. The stream therefore declares no universal primary key. Do not collapse these rows by null ID, name or employee number. With an append destination, select the latest successful scan before counting employees; do not count all historical rows. Preserve the last complete snapshot after a failed scan. An absent employee must be reconciled with HR and app visibility before treating the absence as a deletion. Validate the initial snapshot and a repeat refresh against HR totals and sampled department/status values before switching an existing dashboard.

The connector retries transient HTTP/network failures with a bounded budget; permission failures, malformed pages and repeated pagination tokens fail the run. Employee payloads and app credentials must stay out of operational logs. Use Daspire's existing failed-run visibility and retry workflow; no separate Airflow script is required.

See the Feishu EHR API for the provider contract. HR and the dashboard owner must confirm custom-field mappings and status labels before switching the reporting model.

Authentication modes

Current public setup uses BYOA / custom app credentials. Daspire does not currently provide a public Feishu store app that customers can install from the Feishu marketplace for this source.

BYOA / custom app credentials

Use this mode when the customer creates and owns the Feishu Open Platform app.

Required fields:

Field	Description
App ID	Feishu Open Platform app ID
App Secret	Feishu Open Platform app secret

To get these values:

1. Sign in to the Feishu Open Platform.
2. Create or open a customer-owned custom app for the Feishu tenant.
3. Open the app credentials page and copy the App ID and App Secret. Feishu documents this as the custom-app tenant_access_token flow: self-built app tenant access token.
4. Grant the app the permissions required by the modules you plan to sync.
5. Publish or enable the custom app for the tenant after the tenant administrator approves the permissions.
6. Paste the App ID and App Secret into Daspire.

Daspire exchanges the app ID and app secret for a tenant access token with:

POST https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal

The app secret is stored as an encrypted connector secret.

Store app / marketplace-ready

This mode is reserved for a Daspire-managed Feishu store app or private marketplace deployment. Do not choose it for normal customer-created custom apps.

Daspire does not currently expose a self-service Feishu marketplace app installation flow for this source. A usable store-app setup requires:

• A Daspire-owned Feishu store app that has passed the Feishu marketplace or private deployment review.
• A tenant administrator installing that app.
• A Daspire installation callback that receives the tenant key.
• Daspire-managed app ticket, app access token, and tenant access token lifecycle automation.

Feishu explains the difference between custom apps and store apps in self-built apps and store apps. The token exchange for store apps is documented in store app tenant access token.

Reserved fields:

Field	Description
Tenant Key	Tenant key received by Daspire from a completed store app installation callback
App Access Token	App-level token generated by the Daspire-managed store app token flow
Tenant Access Token	Optional pre-minted tenant token from a Daspire-managed store app deployment

Customers cannot obtain these values from a BYOA/custom app in the Feishu developer console. Use BYOA unless Daspire has explicitly provided store-app installation details for your tenant.

Required permissions

Grant only the permissions required by the modules you enable.

Module	Required Open Platform access
Approval	Read approval definitions, query approval instances, and read approval instance details
Bitable/Base	Read Bitable apps, tables, views, records, and automatic record metadata
Attendance	Export attendance/check-in data for the configured employee ID type. Default all-user sync also needs enough Contact access to enumerate visible users.
Contact	Read basic contact information and the user fields you intend to sync
EHR employee roster	Read employee roster (ehr:employee:readonly)

If the customer uses a custom app, the app must be published or enabled for the tenant after permissions are approved.

Set up Feishu in Daspire

1. Select Feishu from the source catalog.
2. Enter a source name.
3. Choose the authentication mode.
4. For BYOA, enter the Feishu App ID and App Secret.
5. Select Approval, Bitable/Base, Attendance, Contact, EHR Employee Roster, or any combination.
6. For Approval, enter one or more approval codes and a rolling lookback window in days.
7. For Bitable/Base, enter the app token, table ID, and optional view ID.
8. For Attendance, optionally enter employee IDs or employee numbers to filter the sync. Leave empty to scan all users visible to the app, and choose the matching ID type.
9. For Contact, optionally enter department IDs to filter the sync. Leave empty to scan from the root department, and choose the matching department and user ID types.
10. Save and test the source.

Notes

• Approval sync uses an incremental cursor where Feishu supports time-window filtering. A rolling lookback is used to catch updates when the upstream API does not expose a reliable updated timestamp.
• Bitable/Base records preserve table fields as raw JSON. Daspire does not hardcode table-specific field names.
• Attendance and Contact are opt-in modules. When selected, they default to scanning all users and departments visible to the app; filters can narrow the scope.
• Contact enrichment is available as a connector helper for future stream enrichment. The Contact module itself emits user rows only when selected.