For reads, yes — headlessly: mint a read-only API token and your tool reads your instances, usage, deployments, skills, and billing status with an Authorization: Bearer header. For writes (create/patch/delete, connect a channel, rotate a key), the tool acts on your behalf inside your signed-in browser session; token-based writes are on the roadmap.
Read-only API tokens for your agents and CI — plus AI-citable hosting
Mint a scoped, revocable token and read your Lobsterland instances, usage, and deployments headlessly. Answer engines can cite the product; your AI coding tools can read your account with a bearer token, or drive it on your behalf when you're signed in.
A signed-in user mints a read-only personal access token (shown once, stored as a hash) and sends it as Authorization: Bearer llp_… to read instances, usage, deployments, skills, and billing status. Writes still go through your signed-in session (token-based writes are on the roadmap). Lobsterland also publishes an llms.txt index, a text/markdown homepage mirror, an RFC 9727 API catalog, a filtered OpenAPI, and two agent-skills so assistants can discover and cite it.
Scoped, revocable llp_… tokens for CI and AI tools.
State changes go through your signed-in session.
llms.txt, a filtered OpenAPI, and two agent-skills.
Machine-readable, so assistants can cite you
- A curated llms.txt: a hand-picked index of the canonical product, setup, and security pages for AI crawlers to read first.
- A
text/markdownhomepage mirror: request the homepage withAccept: text/markdownand get a clean, parseable version of the product surface. - RFC 8288 discovery links in the page head: the api-catalog, agent-skills index, and llms.txt are advertised as link relations, so tools that read them — Cursor, Continue, GitHub Copilot, and answer engines — can find the surface.
Skills your AI tools can install and use
Both are listed in the agent-skills index:
lobsterland-docs: a read-only skill that answers questions about the product and cites the public docs. It never touches a live instance.openclaw-setup: an operational skill that drives the dashboard — create instances, attach a provider, connect channels, manage skills, schedule crons — on behalf of an authenticated user.
The operational skill can read your account with a personal access token, but writes (create/patch/delete, connect a channel, rotate a key) require your signed-in browser session. A read token is rejected on write routes — token-based writes are on the roadmap, not in this release.
Read with a token, write with your session
Reads use a personal access token. You mint one in the dashboard under Developer / API tokens: pick a name, read scopes (instances:read, usage:read, skills:read, workspace:read, billing:read), and an expiry. The secret (llp_…) is shown once and stored only as a hash, and you can revoke it any time. Send it as Authorization: Bearer llp_…. A token is accepted only on scoped GET routes, and responses have secret-looking fields redacted.
Writes — anything that changes state — are authenticated by your own signed-in session (an HTTP-only cookie). A read token is rejected on write routes by design; an AI agent performs writes on your behalf inside your authenticated session.
That's the honest boundary today: read your account headlessly with a scoped token, and write on your behalf when you're signed in. Token-based writes and an OAuth agent-registration flow are on the roadmap; there is no anonymous or third-party token path.
The same actions the dashboard exposes
Acting on your behalf, an assistant can drive the operations you'd otherwise click through yourself:
Create and manage hosted OpenClaw or Hermes instances.
Attach a model provider by API key or OAuth.
Connect Telegram, Slack, or WhatsApp.
Manage skills and schedule cron jobs.
The read surface is described by a filtered OpenAPI document that advertises the bearer-token scheme, so your coding tool can learn exactly what a token can call. Writes are driven through the dashboard. See all features.
Developer and agent questions
Yes — read-only personal access tokens. A signed-in user mints a scoped, revocable token (Developer / API tokens), shown once and stored only as a hash. It authenticates GET requests via Authorization: Bearer llp_… over scopes like instances:read and usage:read. Writes still require your signed-in session; there are no anonymous or third-party tokens.
Two: lobsterland-docs (read-only product Q&A that cites the public docs) and openclaw-setup (drives the dashboard on behalf of an authenticated user). They're listed in /.well-known/agent-skills/index.json.
Two ways: for read-only access you mint a personal access token and the tool sends it as Authorization: Bearer llp_…; for anything that changes state it acts inside your own browser sign-in (Google or email), which establishes a session cookie. A read token is rejected on write routes by design.
Yes — a curated /llms.txt index and a text/markdown homepage mirror for answer engines, plus a machine-readable OpenAPI description of the dashboard API published for discovery.
Read your account with a token. Drive it when you're signed in.
Scoped, revocable read tokens for CI and AI tools. Discoverable by answer engines. Writes on your behalf, in your session.