Lark
Use the Lark source to replicate Approval, Base, Attendance, and Contact data from a customer-managed Lark tenant into Daspire.
Lark and Feishu appear as separate source entries in Daspire because customers configure them in different Open Platform environments. 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 |
| Base | Supported | Base 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 |
Authentication modes
BYOA / custom app credentials
Use this mode when the customer creates and owns the Lark Open Platform app.
Required fields:
| Field | Description |
|---|---|
| App ID | Lark Open Platform app ID |
| App Secret | Lark Open Platform app secret |
Daspire exchanges the app ID and app secret for a tenant access token with:
POST https://open.larksuite.com/open-apis/auth/v3/tenant_access_token/internal
The app secret is stored as an encrypted connector secret.
Store app / marketplace-ready
Use this mode for marketplace installation flows once the Lark store app callback is connected.
Reserved fields:
| Field | Description |
|---|---|
| Tenant Key | Tenant key from the installation callback |
| App Access Token | App-level token used to mint tenant access tokens |
| Tenant Access Token | Optional pre-minted tenant token |
This mode is modeled in the connector spec, but tenant installation callbacks and app token lifecycle automation are not required for the first BYOA release.
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 |
| Base | Read Base 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 |
If the customer uses a custom app, the app must be published or enabled for the tenant after permissions are approved.
Set up Lark in Daspire
- Select Lark from the source catalog.
- Enter a source name.
- Choose the authentication mode.
- For BYOA, enter the Lark App ID and App Secret.
- Select Approval, Bitable/Base, Attendance, Contact, or any combination.
- For Approval, enter one or more approval codes and a rolling lookback window in days.
- For Base, enter the app token, table ID, and optional view ID.
- 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.
- 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.
- Save and test the source.
Notes
- Approval sync uses an incremental cursor where Lark supports time-window filtering. A rolling lookback is used to catch updates when the upstream API does not expose a reliable updated timestamp.
- 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.