Someone already built it.

A listing is a workflow or an automation that someone else got working, shared as something you can run. You install it — free — bind your own logins and inputs into the slots it declares, and run it: POST /api/marketplace/listings/{slug}/run. You run a listing; you do not read it.

browse ▸ filters

Find one that already works.

GET /api/marketplace/listings takes the filters below, and GET /api/marketplace/listings/{slug} reads one in full. Results carry measured performance, not adjectives.

What a listing card tells you

Every card carries the same measured signals, so two listings for the same job are directly comparable:

• Latency, success rate and on-time rate — measured from real runs.
• A failure-spike flag when recent runs have got worse.
• The creator’s reputation tier.
• Its rank inside the capability set it competes in.

install ▸ free

Installing is free, and it is idempotent.

POST /api/marketplace/listings/{slug}/install puts the listing on your account. Calling it twice does not install it twice — an install is idempotent per account and listing. What lands is a frozen, data-less snapshot: the steps plus the manifest of slots it needs, with the creator’s credentials stripped at publish.

bindings ▸ the seam

You bind your own credentials. That is the whole design.

A listing declares slots: the login it needs, the secret it needs, the inputs it takes. It does not ship the creator’s. You fill the slots with things you own, and a run resolves them from your bindings and from nowhere else. Read the slots with GET /api/marketplace/installs/{slug}/manifest before or after you install.

Setting and clearing one

PUT /api/marketplace/installs/{slug}/bindings sets a slot; DELETE with ?slot_kind= and ?slot_key= clears it. The body is five fields:

Install, bind, run

The four calls in the order you make them.

# 1. See what slots this listing needs before you install it.
curl https://api.usewrit.app/api/marketplace/installs/invoice-puller/manifest \
  -H "Authorization: Bearer $WRIT_API_KEY"

# 2. Install. Free, and idempotent per account + listing.
curl -X POST https://api.usewrit.app/api/marketplace/listings/invoice-puller/install \
  -H "Authorization: Bearer $WRIT_API_KEY"

# 3. Bind YOUR persona and YOUR secret into the slots it declared.
curl -X PUT https://api.usewrit.app/api/marketplace/installs/invoice-puller/bindings \
  -H "Authorization: Bearer $WRIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"slot_kind": "persona", "slot_key": "login", "persona_id": 12}'

curl -X PUT https://api.usewrit.app/api/marketplace/installs/invoice-puller/bindings \
  -H "Authorization: Bearer $WRIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"slot_kind": "input", "slot_key": "account_number", "input_value": "88213"}'

# 4. Run it. Everything it signs in with came from step 3.
curl -X POST https://api.usewrit.app/api/marketplace/listings/invoice-puller/run \
  -H "Authorization: Bearer $WRIT_API_KEY"

// A workflow install declares these slot kinds:
{ "slot_kind": "persona", "slot_key": "login",   "persona_id": 12 }
{ "slot_kind": "secret",  "slot_key": "api_key", "vault_secret_ref": "acme-key" }
{ "slot_kind": "input",   "slot_key": "region",  "input_value": "eu-west" }

// An automation install adds two more:
{ "slot_kind": "monitor_url",      "slot_key": "watch",  "input_value": "https://example.com/pricing" }
{ "slot_kind": "notify_recipient", "slot_key": "alerts", "input_value": "[email protected]" }

// Clearing one is a DELETE with the same two identifiers:
// DELETE /api/marketplace/installs/{slug}/bindings?slot_kind=input&slot_key=region

# Where this install sits against the creator's caps.
curl https://api.usewrit.app/api/marketplace/installs/invoice-puller/usage \
  -H "Authorization: Bearer $WRIT_API_KEY"

# Everything you have installed.
curl https://api.usewrit.app/api/marketplace/installs -H "Authorization: Bearer $WRIT_API_KEY"

# A run went wrong — open a report.
curl -X POST https://api.usewrit.app/api/marketplace/installs/invoice-puller/report \
  -H "Authorization: Bearer $WRIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"reason": "The run signed in but returned no rows."}'

# Your own reports: open | reviewing | resolved | dismissed.
curl https://api.usewrit.app/api/marketplace/reports -H "Authorization: Bearer $WRIT_API_KEY"

run ▸ what is guaranteed

What a run promises.

POST /api/marketplace/listings/{slug}/run executes the listing on your account. Four things hold on every run:

1. It uses your bindings, and only your bindings — Personas, credentials, secrets and inputs are resolved from what you bound. Nothing arrives from the creator.
2. It runs the snapshot you installed — Install captures the recipe as it was that day. A creator editing their live workflow does not change what your install runs.
3. A missing required slot blocks it — The run answers 422 rather than starting and failing halfway. Bind the slot, run again.
4. The listing itself is free — There is no listing charge and no creator fee on a run. What a run can cost is Writ platform compute: nothing on your own machine, metered running time on the managed cloud fleet.

The rest of the lifecycle

Everything else you can do with an install:

reviews ▸ verified runs

Reviews come from people who ran it.

Only someone who installed a listing and accumulated enough successful runs can review it, and an organization gets one review. That is why the ratings track the measured signals instead of drifting from them.

problems ▸ reports

When it does not deliver.

Report the run that went wrong. The creator and the platform admins are notified, and a listing that collects unresolved reports is flagged for review.

publish ▸ creators

Publishing your own.

POST /api/marketplace/publish needs a verified account and accept_creator_agreement: true. Any plan, Free included, may publish, and what you publish is a free recipe: your personas, secrets and sessions are stripped at publish, so what anyone installs can never contain them. The body describes the asset and the guardrails you want on every run of it.

Publish a recipe

The publish call, and the guardrails that ride with it.

curl -X POST https://api.usewrit.app/api/marketplace/publish \
  -H "Authorization: Bearer $WRIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "accept_creator_agreement": true,
    "asset_type": "workflow",
    "workflow_id": 41,
    "title": "Invoice puller",
    "summary": "Signs in and pulls every invoice since a date you pass in.",
    "category": "finance",
    "keywords": ["invoices", "accounting"],
    "tags": ["billing"],
    "intent": "Pull invoices from a billing portal",
    "baseline_duration_ms": 18000,
    "marketplace_exec_policy": "cloud",
    "usage_limits": {
      "per_buyer": { "count": 200, "window": "day", "mode": "enforce" },
      "global": { "count": 20000, "window": "month", "mode": "enforce" },
      "max_concurrent_per_buyer": { "count": 4, "mode": "enforce" }
    },
    "input_rules": {
      "rules": {
        "account_number": { "pattern": "^[0-9]{4,8}$", "message": "4 to 8 digits" }
      }
    }
  }'

// usage_limits — three independent caps, each with its own mode.
// mode:   "off" | "warn" | "enforce"
// window: per_buyer "day" | "month"   ·   global "day" | "month" | "lifetime"
{
  "per_buyer":                { "count": 200,   "window": "day",   "mode": "enforce" },
  "global":                   { "count": 20000, "window": "month", "mode": "enforce" },
  "max_concurrent_per_buyer": { "count": 4,                        "mode": "enforce" }
}

// input_rules — one regex per input or secret slot, checked on every run.
// flags: any subset of "i", "m", "s". message is what the runner is shown.
{
  "rules": {
    "account_number": { "pattern": "^[0-9]{4,8}$", "flags": "", "message": "4 to 8 digits" }
  }
}

ip ▸ run, not read

People run a listing. They do not read it.

If you publish a recipe you spent weeks getting right, sharing it should not mean handing it over. That is a design constraint, not a promise — so here is exactly how it is arranged:

1. Install captures a data-less snapshot — What lands on someone else’s account is the shape of the recipe, without the data it was built against.
2. No install-side endpoint returns the steps — There is no read path for the recipe. Not on the listing, not on the install, not on a run.
3. The desktop path receives a sealed recipe — When a run executes on a machine, that machine receives a form only it can open.

reference ▸ next

Around the marketplace

faq

Marketplace questions, answered.

end ▸ install one

Install one and bind your own login.

The manifest tells you which slots a listing needs before you install it. Read it first, then install.