Feature Request: Add base +record-search command (POST /records/search API)

[xiaotiepen]

Background

Currently, querying records in a Bitable table requires +record-list with client-side filtering. For large tables (2400+ records), this requires 13+ serial API calls and takes 60+ seconds.

The Feishu Open Platform provides a more efficient /records/search API:

• Endpoint: POST /open-apis/bitable/v1/apps/:app_token/tables/:table_id/records/search
• Server-side filtering: supports contains, is, isNot, etc. on any field
• Larger page size: up to 500 records per request (vs 200 for list)
• Result: 1–2 requests instead of 13+, roughly 10–100x faster

Problem with current lark-cli api

Calling this endpoint via lark-cli api silently exits with code 1, no stdout, no stderr:

MSYS_NO_PATHCONV=1 lark-cli api POST "/open-apis/bitable/v1/apps/xxx/tables/yyy/records/search"   --as user --data '{"page_size":5}'
# Exit: 1, no output at all

GET requests to other bitable endpoints work fine via lark-cli api. The issue appears specific to POST /records/search.

Requested Command

lark-cli base +record-search   --base-token <token>   --table-id <table_id>   --filter '{"conjunction":"and","conditions":[{"field_name":"会议名称","operator":"contains","value":["keyword"]}]}'   --sort '[{"field_name":"会议开始时间","desc":true}]'   --field-names '["会议名称","会议开始时间","面试录音"]'   --page-size 500   --page-all

Performance Impact

Searching interview records in a 2400-row Bitable table:

Method	Requests	Time
Current +record-list (full scan)	13 serial calls	60+ sec
Optimized +record-list (range scan)	5 calls	~6 sec
+record-search (server-side filter)	1–2 calls	~1 sec

Reference

• Search records API

[zgz2048]

Thanks for the detailed request and the clear benchmark comparison.

We agree this should be supported. For large tables, record search is significantly more appropriate than asking users to do full scans with +record-list.

The good news is that the underlying search capability is already in place on our side. What we still need to do is expose it cleanly in the CLI. We’re planning to add this in the near term, so this is already beyond the feature evaluation stage.

We also acknowledge the current lark-cli api behavior on this endpoint is poor. The silent exit is not the expected experience, and we’ll review that as part of the follow-up.

We’ll keep this issue updated when the CLI command design and delivery timeline are finalized.