Skip to main content

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