API Claws by Buda

API Claws is Buda's developer-facing Agent API. With a few calls to Buda's REST API at /api/v1, third-party developers can give their products a cloud-hosted AI Agent with conversation capability and a private knowledge base, waking on demand and consuming zero resources at rest. In practice, you are not integrating a raw model API; you are integrating a managed Agent capability layer that already includes model access, runtime, knowledge base, session management, and operational scaling. It is built for smart hardware makers building watches, earbuds, and IoT devices that want a built-in AI assistant; software developers building mini-programs, apps, and browser extensions that want to embed AI chat; and SaaS providers who want to offer customers an "AI-powered private space." Smartwatches, IoT devices, and chat plugins all want built-in AI Agents. But running a large model on-device isn't viable: there is not enough compute, too much power draw, and poor results. Calling an LLM API directly also falls short, because a raw model API only gives you model output. You are left to manage sessions yourself, build retrieval, build orchestration, design multi-tenant support, and run operations. API Claws closes that gap. It gives you an operational AI Agent instead of a text or structured completion, with a built-in session model, Drive-based knowledge included, a managed Agent runtime, Space-based isolation built in, and operations managed by Buda. At the heart of API Claws are Spaces and Agents. A Space is the tenant boundary, customer boundary, or device fleet boundary, controlled by the Space API at /api/v1/spaces. You use a Space whenever you need isolation between customers, teams, devices, or paid accounts. Inside a Space lives the managed Claw Agent, controlled by the Agent API at /api/v1/spaces/{spaceId}/agents. Each tenant or product line can have its own assistant role and instructions, so different users can have different Agent configurations; to do that, you create separate Spaces and Agents per user as needed. Buda also provides a concise developer-facing hosted Agent collection through the API Agents API at /api/v1/api-agents, which lets you list or provision API Claws with a plain REST resource name. The Drive API at /api/v1/api-agents/{agentId}/drive/files holds durable knowledge, manuals, policies, state, and long-lived memory. This matters because the useful pattern is not "send everything in every prompt." Instead, your product treats Drive as the Agent's durable brain: you write product manuals, policies, release notes, and user-specific state into Drive, and the Agent keeps improving from files rather than receiving the same giant prompt every time. Files persist across sessions, and updating a file updates what the Agent can use on the next run. Buda can create, overwrite, browse, rename, and delete Drive files, list files and folders, and issue presigned upload and download URLs, so a device or third-party app gets an Agent that improves over time. The Chat Session API at /api/v1/api-agents/{agentId}/sessions covers user conversations, async Agent runs, status, and messages. When you send a message, Buda returns a session.id, starts the Agent run asynchronously, and you poll the session until the status becomes completed, waiting_for_input, failed, or cancelled. Each end user gets an independent Chat Session with isolated context. The Embed API adds a hosted iframe surface and a frontend-safe path: your backend mints a short-lived embed URL or embed session token, and a browser, mobile app, mini-program, or extension can talk to Buda without seeing your main API Key. Agents also support scheduled tasks, which can be listed, created, enabled, disabled, and run immediately with run history. The way API Claws works is deliberately infrastructure-first. A request authenticates with your API Key, resolves to a Space (tenant boundary), reaches the Agent and its Drive (knowledge base), and runs inside a Chat Session, gated by a credit check against the Space's usage balance rather than a per-request rate limit. The Agent sleeps when idle and wakes automatically when a message arrives, so it consumes zero resources when idle and no infrastructure sits behind every device. The recommended lifecycle is provision, seed, run, read, learn, and update: the API call wakes the Agent, the session captures the immediate conversation, and Drive carries forward the durable knowledge. API Claws sits on top of OpenClaw; OpenClaw is the underlying Agent runtime and capability model, while API Claws is the developer-facing integration layer built on top of it. The key value is that your team can focus on the product experience while Buda provides the Agent infrastructure layer behind it. With API Claws, the developer does not need to separately build or operate model configuration and provider switching, inference machines or GPU infrastructure, the Agent runtime and tool sandboxing, file ingestion and knowledge base processing, session and context management, tenant isolation for different users or customers, or wake/sleep orchestration for idle agents. For hardware companies, this changes the cost structure: there is no need to ship a device powerful enough to run a full AI stack locally, no need to keep a user's laptop or phone acting as the primary runtime, and no need to maintain a separate AI backend team just to support one device line. Your hardware can stay lightweight while the AI capability keeps improving in the cloud. API Claws is used across several concrete scenarios. A smart hardware fleet can map one Space per customer, fleet, or premium device group, one Agent per device model or assistant role, with manuals, firmware notes, troubleshooting guides, and device state snapshots in Drive; the device backend starts sessions when the user speaks or a device event occurs. A WeChat mini program can use one Space per merchant, course, customer, or end-user account, with an Agent per business function such as support, tutor, or shopping assistant, and its backend mints an embed session for the user's openid. A SaaS copilot can use one Space per customer tenant and one Agent per workflow such as onboarding, reporting, or support. A customer support widget can run one support Agent per brand or queue and create one embed URL per visitor. An internal enterprise Agent can use one Space per department or project with multiple Agents for ops, sales, research, or engineering. API Claws is for two common buyer types: chat apps, SaaS tools, and third-party software that already have users, conversations, forms, or workflows; and hardware manufacturers building smartwatches, earbuds, voice terminals, or other connected devices. Integration is straightforward: register a developer account and get an API Key, create a Space, create an Agent inside it, add durable knowledge to Drive, start a conversation, and poll the session result. Buda exposes the endpoints in an OpenAPI JSON at /api/v1/openapi.json and an interactive Swagger UI at /api/v1/doc, and an official Rust CLI, buda-cli, wraps every /api/v1 route. Buda runs a self-built Kubernetes cluster (Claw Computer) with elastic scaling. On billing, Buda charges per Space, not per end user: you buy Spaces from Buda with volume pricing available, charge your end users a subscription or activation fee, and keep the margin. In summary, API Claws turns a product's AI ambitions into a few REST calls. It gives hardware and software teams a managed, multi-tenant Agent capability layer, with model access, runtime, Drive knowledge base, sessions, embeddings, and scaling included, so they can ship a cloud AI brain behind watches, apps, and SaaS tools without operating inference infrastructure, and with an Agent that keeps improving over time.