API reference

The apiary's data-access API is the HTTP surface of the local honeycomb daemon. The daemon is the only process that talks to storage, every other surface, the CLI, the lifecycle hooks, the MCP server, the SDK, is a thin client that reaches storage through this API.

#Where does the API live and do I need a key?

The daemon serves everything from one HTTP server, by default on 127.0.0.1:3850. The port, host, and bind address can be overridden with HONEYCOMB_PORT, HONEYCOMB_HOST, and HONEYCOMB_BIND for a team deployment that needs to widen the bind beyond localhost.

There are three daemon modes:

Login uses a device-flow sign-in and mints a long-lived, org-bound token, stored locally and sent in an HTTP Authorization header, never in a URL. Remote connectors instead use named API keys, prefixed hc_sk_..., stored hashed, and printed once at creation.

#What are the route groups?

#What roles exist, and what can each one do?

Every route that touches your data is scoped within your org and workspace, enforced at the storage layer, not just at the request layer, so a token minted for one company cannot read another company's data by editing a header.

#What do the status codes mean?

Errors return a plain, structured message, never a raw stack trace and never an upstream provider's error verbatim.

#What can I do with the API that the CLI does not cover?

The API is the same surface the CLI, the SDK, and the MCP server all use underneath, so anything they can do, the API can do directly. Reach for it when you are building a custom integration, need a non-JavaScript runtime, or want a route the SDK has not wrapped yet.

#Representative endpoints

There is deliberately no way to read a stored secret's value back through the API.

#How do I call the API from an application?

Use the typed @honeycomb/sdk client, which wraps the daemon API and works in Node, Bun, and the browser:

import { HoneycombClient } from "@honeycomb/sdk";

const honeycomb = new HoneycombClient({
  daemonUrl: "http://localhost:3850",
  token: "Bearer hc_sk_...",
  actor: "agent-name",
  actorType: "llm",
});

await honeycomb.remember("prefers TypeScript", { importance: 0.9, tags: "language" });
const { results } = await honeycomb.recall("language preferences", { limit: 5 });

The client covers memory, hooks, connectors, skills, goals, health, and the value-safe secrets surface. GET requests retry automatically, mutating requests do not, since mutations are not idempotent. Errors come back typed: an API error for non-2xx responses, a network error for transport failures, and a timeout error when a request runs past its budget.

#Common questions

#Where does the API live and do I need a key?

It is served by the local honeycomb daemon, by default at 127.0.0.1:3850. On a single developer's machine, in local mode, no authentication is required. Team and hybrid deployments require a bearer token or an API key on every request.

#What can I do with the API that the CLI does not cover?

The API is the same surface the CLI, the SDK, and the MCP server all use underneath, so anything they can do, the API can do directly. It is the right choice when you are building a custom integration or need a non-JavaScript runtime.

#How do I call the API from an application?

Use the typed @honeycomb/sdk client, which wraps the daemon API with methods like remember and recall and works in Node, Bun, and the browser. It handles retries on read requests and typed errors for you.