Worked marketplace samples
The endpoint list below documents every operation’s parameters; this overlay walks a listing the way a builder actually uses it: browse the public catalog → fetch one listing’s installable config → install it → handle the draft-listing 404. Success envelopes are{ data, meta },
error envelopes { error, meta } — see How to read a worked
sample. The catalog read is unauthenticated;
install requires the owner, admin, or developer role and the paid listing
credits/debits the org wallet on install.
Every response carries meta.request_id. Quote the request id when you
report a listing that was approved but the install fails, or an install
that deducted the wallet without returning the agent it materialised.
1. Browse the public catalog
GET /api/v1/marketplace returns the catalog’s published listings.
No authentication is required; draft, pending-review, and rejected
listings are never exposed. Page forward with the cursor from
meta.pagination.cursor, and narrow the catalog with type.
200
2. Fetch one listing’s config
GET /api/v1/marketplace/{id} returns one published listing with the
full config — the payload installing copies into your workspace. The
agent definition, flow graph, integration settings, and tool pack are
all readable on a published listing; never place API keys or other
secrets in a submitted config.
200
3. Install a listing
POST /api/v1/marketplace/{id}/install materialises a published listing
into your workspace. An agent template comes in as a new draft agent;
other types copy their configuration directly. An identical install
returns the existing artifact — the POST is a one-shot idempotent.
200
4. Errors
Errors follow the{ error, meta } envelope. The failure every
integrator hits:
404 — draft, pending, or rejected listing. The route never leaks an
unapproved config through a guessed id; fetch GET /api/v1/marketplace/mine for any lifecycle state your own org authored.
404