Feishu / Lark IM Skill

Use this skill to run Feishu or Lark IM operations through uxc + OpenAPI.

Reuse the uxc skill for shared execution, auth, and error-handling guidance.

Prerequisites

• - uxc is installed and available in PATH.
• Network access to https://open.feishu.cn/open-apis or https://open.larksuite.com/open-apis.
• Access to the curated OpenAPI schema URL:

• - A Feishu or Lark app with bot capability enabled.
• A Feishu or Lark app app_id + app_secret, or a current tenant_access_token if you are using the manual fallback path.

Scope

This skill covers an IM-focused request/response surface:

• - chat lookup
• chat member lookup
• image and file upload for IM sends
• message send and reply
• selected message history reads
• basic user lookup through contact APIs

This skill does not cover:

• - docs, bitable, approval, or non-IM product families
• the full Feishu or Lark Open Platform surface

Subscribe Status

Feishu and Lark expose event-delivery models beyond plain request/response APIs, including long-connection event delivery in the platform ecosystem.

Current uxc subscribe status:

• - request/response IM operations are validated
• inbound message intake is validated through the built-in feishu-long-connection transport
• live validation confirmed real im.message.receive_v1 events delivered into the subscribe sink for a p2p bot chat

Important runtime notes:

• - feishu-long-connection is a provider-aware transport inside uxc subscribe; it is not a plain raw WebSocket stream
• the runtime opens a temporary WebSocket URL from INLINECODE16
• frames are protobuf binary messages, not text JSON
• the runtime sends required event acknowledgements and ping control frames automatically

Endpoint Choice

This schema works against either Feishu or Lark Open Platform base URLs:

• - China / Feishu default: INLINECODE17
• International / Lark alternative: INLINECODE18

The fixed link example below uses Feishu. For Lark, use the same schema URL against the Lark base host.

Authentication

Feishu and Lark service-side APIs use Authorization: Bearer <tenant_access_token> for these operations.

Preferred setup is to store app_id + app_secret as credential fields and let uxc auth bootstrap fetch and refresh the short-lived tenant token automatically.

Feishu bootstrap-managed setup:

CODEBLOCK0

For Lark, use the same bootstrap shape against the Lark host and bind the credential to open.larksuite.com.

To use long-connection subscribe, the credential still needs app_id and app_secret fields because the transport opens its own temporary event URL outside the normal bearer-token request path.

Manual fallback if you already have a tenant token:

CODEBLOCK1

Lark uses the same path shape on the Lark host:

CODEBLOCK2

Configure one bearer credential and bind it to the Feishu API host:

CODEBLOCK3

For Lark, create the same binding against open.larksuite.com:

CODEBLOCK4

Inspect or pre-warm bootstrap state when auth looks wrong:

CODEBLOCK5

Validate the active binding when auth looks wrong:

CODEBLOCK6

Core Workflow

1. 1. Use the fixed link command by default:

1. 2. Inspect operation schema first:

1. 3. Prefer read/setup validation before writes:

1. 4. Execute with key/value or positional JSON:

1. 5. For inbound message intake, use uxc subscribe directly:

Operation Groups

Chat Reads

• - INLINECODE44
• INLINECODE45
• INLINECODE46

Message Reads / Writes

• - INLINECODE47
• INLINECODE48
• INLINECODE49
• INLINECODE50

Uploads

• - INLINECODE51
• INLINECODE52

User Lookup

• - INLINECODE53
• INLINECODE54

Guardrails

• - Keep automation on the JSON output envelope; do not use --text.
• Parse stable fields first: ok, kind, protocol, data, error.
• Prefer uxc auth bootstrap over manual token management. Manual tenant_access_token setup is still supported as a fallback.
• INLINECODE63 requires the app credential fields app_id and app_secret; a plain bearer-only credential is not enough for event intake.
• INLINECODE66 and post:/im/v1/files use multipart/form-data. File fields must be local path strings; help output marks them as multipart file fields.
• INLINECODE69 requires the receive_id_type query parameter and the body content field is a JSON-encoded string, not a nested JSON object.
• Upload first, then send by returned key:

• - post:/im/v1/messages/{message_id}/reply is for explicit replies to an existing message. Treat it as a high-risk write.
• History reads only return chats and messages visible to the bot/app configuration. Auth success does not imply access to every chat.
• Long-connection message intake is validated for Feishu bot chats; webhook-style callbacks and non-IM products are still out of scope.
• INLINECODE77 is equivalent to uxc https://open.feishu.cn/open-apis --schema-url <feishu_openapi_schema> <operation> ....

References

• - Usage patterns: INLINECODE79
• Curated OpenAPI schema: INLINECODE80
• Feishu Open Platform docs: https://open.feishu.cn/document/
• Lark Open Platform docs: https://open.larksuite.com/document/