KakaHub Documentation

The documentation and catalog are public read surfaces. Visitors can browse skills, plugins, agents, and asset packs without creating an account.

Login is only required when a user or automation wants to publish a package, manage publisher metadata, or access private organization-scoped resources.

• Search and detail pages are designed for anonymous external readers.
• Public resources expose README, manifest, owner, version, permissions, artifact size, and checksum.
• Private and organization-scoped resources remain hidden unless the caller is authenticated and authorized.

GET /docs
GET /api/v1/search?type=skill&q=design
GET /api/v1/skills/<slug>
GET /api/v1/plugins/<package-name>

Use KakaHub as an OpenClaw-compatible registry. The site keeps the install surface aligned with the OpenClaw ecosystem: skills install by slug, while plugins resolve through the clawhub: package prefix.

When running against your own KakaHub registry instance, point OpenClaw or compatible tooling at the registry URL before searching or installing.

• Skill install uses the skill install resolver and downloads the checked artifact.
• Plugin install uses the package artifact resolver for OpenClaw plugin bundles.
• Downloaded artifacts include sha256 checksums so clients can fail closed on mismatch.

OPENCLAW_REGISTRY=https://hub.example.com openclaw skills search "design"
OPENCLAW_REGISTRY=https://hub.example.com openclaw skills install <skill-slug>
OPENCLAW_REGISTRY=https://hub.example.com openclaw plugins install clawhub:<package-name>

OpenClaw clients and AI agents can discover KakaHub from either the KakaHub well-known file or the ClawHub-compatible alias. Both return API base URLs, supported install commands, publish scopes, and required archive entries.

Agents should use read endpoints for discovery and resolver endpoints for artifacts instead of scraping HTML pages.

• Discovery endpoints are public.
• Catalog read endpoints are bounded and paginated.
• Publishing clients must send Authorization: Bearer <token> with the required scopes.
• Agents should store the artifact checksum and owner handle alongside installed resources.

GET /.well-known/kakahub.json
GET /.well-known/clawhub.json
GET /api/v1/search?type=plugin&q=calendar
GET /api/v1/skills/<slug>/install
GET /api/v1/plugins/<package-name>/versions/<version>/artifact

Publishing works like a package registry. Upload a zip archive for a skill or plugin, include the manifest expected by the ecosystem, and let KakaHub validate the archive before persistence.

The backend validates zip structure, unsafe paths, duplicate paths, archive size, compression ratio, sha256, and required manifest entries. A failed validation does not create a release.

• Use Studio for an interactive browser flow.
• Use API tokens for automation, CI, OpenClaw agents, or publisher bots.
• Skill publish tokens require publish:skill and manage:publisher.
• Plugin publish tokens require publish:plugin and manage:publisher.

Skill archive: SKILL.md or kakahub.json
OpenClaw plugin archive: openclaw.plugin.json, .codex-plugin/plugin.json, or kakahub.json
POST /api/v1/skills
POST /api/v1/plugins

Create a scoped token from the account workspace, then send it as a bearer token. Keep tokens out of manifests, README files, and public agent prompts.

A publisher handle controls ownership. For organization publishers, the account behind the token must be an owner or admin of that publisher.

• Prefer the narrowest scopes needed by the agent or CI job.
• Rotate tokens when maintainers leave a publisher organization.
• Dry-run publish requests can be used before creating the version.

Authorization: Bearer <token>
POST /api/v1/tokens  { "scope": ["read:catalog", "publish:skill", "manage:publisher"] }
POST /api/v1/skills  { "publisher": "your-org", "name": "review-helper", "version": "1.0.0", "artifact": { "fileName": "review-helper-1.0.0.zip", "sha256": "<sha256>", "base64": "<zip-base64>" } }