HTTP API Overview

The WarmHub HTTP API exposes mounted JSON endpoints for repository reads, action observability, callbacks, MCP HTTP transport, and SSE.

Repository data writes and management operations are not REST CRUD endpoints. Use the SDK, CLI, or MCP tools for those workflows.

WarmHub does not currently publish an OpenAPI specification. For exact request and response shapes, see the documentation in this section or the SDK reference.

A minimal request

The most common HTTP task is reading a repository’s current state — its HEAD. This is a GET, so it is safe to retry; reads on a public repo also work without a token.

curl -H "Authorization: Bearer <token>" \
  "https://api.warmhub.ai/api/repos/warmhub-data/us.congress.trades/head?shape=CongressTrade&kind=thing&limit=1"

{
  "items": [
    {
      "wref": "CongressTrade/20034954/bd598743649e738e-2",
      "name": "20034954/bd598743649e738e-2",
      "kind": "thing",
      "active": true,
      "shapeName": "CongressTrade",
      "version": 1,
      "data": { "ticker": "CSCO", "amount_range": "$1,001 - $15,000", "transaction_type": "sale_partial" }
    }
  ],
  "nextCursor": "whc1_eyJ2Ijox..."
}

The rest of this page covers the base URL, auth, formats, and retries that apply across endpoints; the routing table points to each endpoint family.

Base URL

Most REST endpoints use the /api prefix:

https://api.warmhub.ai/api/

Root-mounted transports use the origin without /api:

https://api.warmhub.ai/mcp
https://api.warmhub.ai/sse

For example, the repository HEAD endpoint is:

https://api.warmhub.ai/api/repos/acme/world/head

Authentication

Authenticated endpoints require an Authorization header with a Bearer token:

curl -H "Authorization: Bearer <token>" \
  https://api.warmhub.ai/api/repos/acme/world/head

Repository data read endpoints (/head, /about/:wref, /query) on public repositories can be read anonymously; the same endpoints on private repos require authentication. Action-observability endpoints (/api/repos/:org/:repo/actions/*) and MCP POST endpoints (POST /mcp, POST /mcp/:org/:repo) always require authentication regardless of repo visibility — see the per-endpoint Auth column on the Endpoints page.

PAT management REST endpoints are not currently mounted. Create and manage PATs with the CLI (wh token) or the SDK (client.token.*); see Authentication.

Request Format

Content-Type: application/json for JSON request bodies
Path parameters: URL-encoded (for example, Shape%2FMyShape for Shape/MyShape)
Query parameters: Standard URL query string format

Response Format

Repository read and action observability endpoints return JSON on success. The /sse endpoint streams text/event-stream, and MCP endpoints follow JSON-RPC over HTTP.

Most REST errors use this envelope:

{
  "error": {
    "code": "NOT_FOUND",
    "message": "Thing not found: Sensor/temp-1"
  }
}

Two error codes carry an additional machine-readable error.details arm that callers can branch on:

VALIDATION_ERROR — emitted for request validation failures. error.details contains structured field-level validation issues. The top-level error.message reflects the first validation issue encountered (for example, "Expected number, received string"), so callers should not match on a fixed message literal; branch on error.code instead.

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Expected number, received string",
    "details": {
      "reason": "validation_failed",
      "issues": [
        { "path": "limit", "message": "Expected number, received string" }
      ]
    }
  }
}

issues[].path is a dotted string (e.g. "limit" or "body.name") identifying the field that failed validation.

RATE_LIMITED — error.details contains structured retry metadata. Callers should also inspect the Retry-After response header (see Idempotency and retries).

{
  "error": {
    "code": "RATE_LIMITED",
    "message": "Rate limit exceeded",
    "retryAfter": 4,
    "details": {
      "reason": "rate_limit_reset",
      "retryAfterSeconds": 4,
      "resetAt": "2024-06-01T00:00:04Z"
    }
  }
}

The top-level error.retryAfter field (in seconds) is the stable field to read for retry timing; error.details carries the same value alongside reason and resetAt for callers that need the structured form.

Other error codes may also populate error.details when the domain error carries structured context; treat it as an optional, code-specific extension. When error.details is absent, the code and message fields are sufficient for error handling.

HTTP Status	Common Error Codes
`400`	`VALIDATION_ERROR`, `SHAPE_MISMATCH`, `RESERVED_NAME`, `ILLEGAL_OP_SEQUENCE`
`401`	`UNAUTHENTICATED`
`403`	`FORBIDDEN`
`404`	`NOT_FOUND`
`409`	`CONFLICT`, `ARCHIVED`
`413`	`PAYLOAD_TOO_LARGE`
`429`	`RATE_LIMITED`
`500`	`INTERNAL_ERROR`

SDK callers receive these as WarmHubError.code / kind. See the ErrorKind reference for retryability and corrective actions per kind.

Repository read endpoints (/head, /about/:wref, /query) collapse missing-repo and unauthorized-private-repo cases into the same 404 so repo existence stays opaque. Action observability endpoints also collapse anonymous, under-scoped, and missing-repo deny paths to opaque 404 responses. See Queries and Actions for the full deny-path behavior.

Early /sse failures use the same standard envelope as other REST errors. A missing ticket parameter returns 400 VALIDATION_ERROR; an invalid ticket returns 401 UNAUTHENTICATED. Both follow the { "error": { "code": "...", "message": "..." } } shape shown above.

When REST endpoints return 429 RATE_LIMITED, they may include a Retry-After response header. Clients should back off until that interval has elapsed.

A 413 PAYLOAD_TOO_LARGE is returned when a request body exceeds the endpoint’s size limit. The SDK’s write helpers stay under the limit automatically, so you generally only see this on oversized requests built by hand.

Idempotency and retries

GET endpoints — repository reads and action observability — are idempotent. Retrying one returns the same result with no side effects, so they are always safe to retry after a network error.

When a request returns 429 RATE_LIMITED, the response may carry a Retry-After header. The same value is mirrored in the body as error.retryAfter (in seconds). Back off until that interval has elapsed before retrying.

The action callback endpoint, POST /api/action-runs/:runId/callback, is safe to retry with the same status: re-reporting a status the run has already reached succeeds without repeating side effects such as notifications. Reporting a status that conflicts with the run’s current state returns 409 CONFLICT. A retry_requested status is the exception — it is a command, not a report, so each accepted one queues a new delivery attempt and it is rejected once the run’s attempts are exhausted.

WarmHub does not accept an inbound Idempotency-Key header. For action delivery, WarmHub sends your webhook handler an X-WarmHub-Idempotency-Key header so the handler can recognize and discard duplicate deliveries.

Pagination

Pagination behavior differs by endpoint family:

Repository query endpoints (/head, /about/:wref, /query) — accept limit and cursor; return a nextCursor field when more pages are available. Pass nextCursor as cursor on the next request.
Action runs (GET /api/repos/:orgName/:repoName/actions/runs) — accept limit, since, and cursor; since and cursor are mutually exclusive and cannot be combined in the same request. Returns a nextCursor field when more pages are available.
Action notifications (GET /api/repos/:orgName/:repoName/actions/notifications) — accept limit and since only; returns a plain array with no cursor-based pagination.

See Actions for the per-endpoint details.

Parameter	Description
`limit`	Maximum number of items to return per page.
`cursor`	Opaque pagination token from a previous response’s `nextCursor` field. Supported on repository query endpoints and the action runs endpoint. Cannot be combined with `since` on the action runs endpoint.
`since`	Filter action records after this epoch-milliseconds timestamp. Cannot be combined with `cursor` on the action runs endpoint.

Endpoint reference

Need	Page
The complete map of mounted endpoints + per-endpoint auth	Endpoints
Authenticate requests and manage tokens	Authentication
Read repository data (HEAD, about, query)	Queries
Action observability and the callback endpoint	Actions
Rate limits and backoff behavior	Rate Limiting

Endpoints is the complete map — including the surfaces handled through the SDK, CLI, and MCP rather than REST.