Lark OAPI SDK for Python

Lark OAPI (lark-oapi) is the official Python SDK for the Feishu and Lark open platform, which exposes server-side capabilities for messaging, contacts, approvals, spreadsheets, Bitable and many other services. The SDK wraps the common plumbing developers would otherwise build themselves: access-token acquisition and refresh, request signing, data encryption/decryption, event dispatch, and typed request/response models.

You build a Client with your app credentials and call service methods through a fluent, builder-style API grouped by product domain (for example client.im.v1.message.create). It also supports long-connection (WebSocket) event handling, card callbacks, and a keyless client-assertion mode for token exchange.

What You Get

• A fluent Client with builder-style requests across messaging, contacts, docs, Bitable and dozens more services.
• Automatic app and tenant access-token acquisition, caching and refresh.
• Event subscription and card-callback dispatch, including WebSocket long-connection mode.
• Request encryption/decryption, signature verification and typed request/response models.

Common Use Cases

• Building Feishu/Lark bots that send and react to messages.
• Syncing contacts, approvals or documents between Lark and internal systems.
• Handling event subscriptions and interactive card callbacks in a server app.

Under The Hood

Architecture

Lark OAPI centers on a Client (built via a builder) composed of versioned service namespaces generated from the open-API catalog under lark_oapi/api/; a core transport layer handles token management, request signing and (de)serialization, while separate event, card and ws modules dispatch subscriptions and callbacks, and an adapter layer bridges web frameworks.

Tech Stack

Python 3.8+ packaged via setup.py, using requests for HTTP and websockets-style long connections for event streaming; a very large, largely generated API surface with sample scripts under samples/ and a modest core test suite.

Code Quality

The hand-written core (client, transport, tokens, serialization, config) is clean and tested under lark_oapi/core/tests, while the vast api/ tree is generated and uniform; overall the split keeps the maintained surface small and the generated surface consistent, though generated code dominates line count.

API Design

The builder-based fluent API is ergonomic and consistent - Client.builder(), request builders and client.<service>.<version>.<resource>.<action> reads well - and token/security plumbing is hidden, though the sheer breadth of services and builder verbosity add some ceremony.