SkillHub API

Authentication

Public Skill API endpoints can be inspected without a Project Key. Runtime and workspace operations require signed-in context and scoped credentials.

Public Skill API endpoints

Use skill search endpoints to list public Skills, filter by task, runtime, verification state, and permission profile.

Manifest inspection

Skill detail endpoints expose manifest, schema, permissions, version, publisher, and review state before adoption.

Project Key runtime endpoints

Runtime invocation should authenticate with a Project Key created inside a signed-in project.

Errors and rate limits

API clients should handle validation errors, unauthorized calls, policy blocks, rate limits, missing Project Keys, and payment configuration gates.

Example request

POST /v1/runtime/invoke with Authorization: Bearer PROJECT_KEY and a Skill slug plus typed input payload.

Which path should developers use first?

Start with public discovery when you are evaluating Skills, then move to project runtime only after the team has chosen a workflow and reviewed permissions.

• Discovery: browse categories, compare publishers, and inspect manifest metadata without a key.
• Adoption: sign in, create a project, and save the Skill only when the team plans to reuse it.
• Runtime: call REST only from a trusted server or approved automation environment with a scoped Project Key.

Request and response contract

A production client should treat each Skill as a typed contract: validate input before sending, handle structured output, and store invocation IDs for audit follow-up.

• Send the Skill slug, version preference when needed, and a typed payload that matches the manifest schema.
• Expect policy blocks, validation errors, rate limits, and unavailable runtime states as normal client branches.
• Record request time, project id, Skill slug, response status, and returned invocation id without logging secrets.

Operational checklist before production

Before running the API in a customer-facing workflow, check ownership, key scope, retry behavior, logs, and manual fallback.

• Keep Project Keys server-side and rotate them when owners or environments change.
• Use idempotency or job identifiers for workflows that can be retried.
• Keep a human review step for high-risk permissions, customer data, billing, or external writes.