This section is lookup material. Every page names the source files that govern it and the test suites that exercise them, listed at the foot of the page under Source of truth and Verified by, and the largest tables here are not written by hand at all: they are extracted from the code when the site is built. The documentation site covers both mechanisms: what those two frontmatter fields oblige a page to, and which generator emits which table.
The current broker and proxy line is 1.5.3. The JavaScript, Python, Go and Rust clients,
queen-protocol and queenctl remain on their compatible 1.3.0 releases; PHP is prepared for
Packagist but has no tagged release, and C++ is consumed directly from a repository tag or commit.
What is generated from source
| Table | Extracted from | Appears on |
|---|---|---|
| Every route, with its access level and whether it resolves a tenant | the axum router in server/src/main.rs plus the access-level map in server/src/auth.rs |
HTTP conventions and Route table |
| Every environment variable with the default the code applies | server/src/config.rs, plus server/src/fusion.rs for the experiment-only overrides |
the configuration page in this section |
| Every Prometheus metric family | the broker’s metrics module | the Prometheus page in this section |
| What a tenant may call through the multi-tenant gateway | proxy/ |
the proxy pages in Self-hosting |
A generated table cannot drift into documenting a route that does not exist. Hand-written prose can, which is why the pages around those tables stay short and mechanical.
Every row in those tables is answered by every broker. The key/value and timer routes are registered unconditionally, and their metric families are exposed by a broker that has never seen a key or a timer, at zero rather than absent, so an alert can be written before the first tenant arrives.
The message plane
Five routes are the whole data path. Everything else in the HTTP API is queue management, inspection or operations.
HTTP conventions
Base URL, authentication and the access-level role set, error bodies, the empty-204 rule, the body cap. Read this before the route pages.
POST /api/v1/push
Every request field, the per-item response array, all four item statuses, and how deduplication decides.
The pop routes
All three of them, every query parameter with its default, the response field by field, and what a popped message does not carry.
POST /api/v1/ack
Ack as an offset commit: the status values, the per-item result fields, and what an already-committed or unresolvable ack returns.
POST /api/v1/transaction
Pushes and acks in one PostgreSQL transaction: the bundle shape, every rollback cause, and the result array.
POST /api/v1/lease/:leaseId/extend
Extending a lease while a handler is still working, and what a failed extension means.
Route table
Every method and path the broker registers, with access level and tenant scoping, on one searchable page.
The rest of this section
The sidebar lists these pages under Reference. They are grouped by what you are looking up rather than by which component implements it.
| Looking for | Where it lives |
|---|---|
| The remaining HTTP routes: queues, consumer groups, messages and DLQ, traces, status, analytics, system | HTTP API, one page per group |
| The key/value routes and the timer routes, served by every broker | kv and timers |
| The routes of the in-memory storage class, and what each refusal on it means | ephemeral |
| A client library’s methods and builder chain | JavaScript, Python, Go, Rust, PHP, C++ |
The embedded broker’s Rust surface: BrokerConfig, Broker methods, error mapping (beta) |
Engine (Rust), argument by argument. Embed the engine is the how-to that precedes it |
| Command-line usage | queenctl |
| Environment variables and their defaults | Configuration, generated |
Queue options accepted by /api/v1/configure |
Queue options |
| Prometheus metric families | Prometheus, generated |
| HTTP status codes and error strings | Errors |
| Effective defaults, including the values that differ depending on how a queue was created | Defaults |
| Which client versions work with which broker | Compatibility |
Reading order
Reference pages assume you already know what a partition, an offset commit and a lease are. When a route’s behaviour looks arbitrary, the explanation is usually one level down in the model rather than in the route itself.
| If you want | Go to |
|---|---|
| The concepts the routes are built on | Use Queen |
| To run the broker | Self-hosting |
| Why the storage engine behaves this way | Internals |
| Measured throughput, with the configuration that produced it | Benchmarks |
The route pages tell you what a call does; the internals pages tell you why it cannot do otherwise. The four questions readers of this section ask most often are answered one level down, not on the route page.
| The question a route page raises | The page that answers it |
|---|---|
| Why a push of N partitions costs one commit, and where the second deduplication layer sits | Life of a push |
| Why a pop can return 204 while the queue has messages, and what a lease costs | Life of a pop |
| Why the broker makes a request wait instead of answering 429, and why raising the ceiling does nothing | Flow control |
| What the suites named under Verified by at the foot of each page actually run | Testing |