Skip to main content

Listings

A listing represents something for sale on ZAM. It has a title, an optional price, and a run contract that tells ZAM how to execute it. Every listing belongs to exactly one user (the seller) and moves through a state machine:
draft → published → paused → archived

         paused ──┘
StateMeaning
draftVisible only to the seller. Cannot be activated.
publishedLive on the marketplace. Buyers can activate it.
pausedTemporarily hidden. Can be republished.
archivedPermanently retired. Terminal state.
Only published listings appear in marketplace search results or accept activations.

Run contracts

A run contract defines how ZAM executes a listing. It contains:
FieldRequiredDescription
methodYesHTTP method (GET, POST, PUT, PATCH, DELETE)
endpointPathYesThe URL ZAM calls when a buyer activates the listing
inputSchemaNoJSON Schema describing the expected request body
outputSchemaNoJSON Schema describing the response
requestExampleJsonNoExample request for documentation
responseExampleJsonNoExample response for documentation
When a listing has an inputSchema, ZAM validates the buyer’s request body against it before executing. Malformed input never reaches the seller’s endpoint.

Orders

An order records one activation of a listing. When a buyer activates a listing, ZAM:
  1. Validates the request body against the listing’s inputSchema (if present).
  2. Creates an order in pending state.
  3. Calls the seller’s endpoint with the request body.
  4. Updates the order to completed (with the response) or failed (with the error).
pending → running → completed
                  → failed
If the seller’s endpoint responds within 50ms, the POST /v1/orders response contains the final result. Otherwise, it returns the order in pending state and the buyer polls for the result.

Authentication

ZAM supports two authentication methods:
  • API keys — for programmatic access. Pass the key in the x-zam-api-key header. Keys use scoped permissions (listing:create, order:read, etc.).
  • Session cookies — for browser-based access through the dashboard. Managed by the sign-in flow.
API keys start with zam_ and are shown only once at creation time. Store them securely.

Scopes

Each API key carries a set of scopes that control what it can do:
ScopePermission
listing:createCreate listings
listing:readRead own listings
listing:updateUpdate own listings
listing:deleteDelete own listings
order:createActivate listings (create orders)
order:readRead own orders
api_key:createCreate new API keys
api_key:readList own API keys
api_key:updateUpdate own API keys
api_key:deleteDelete own API keys
Grant the minimum scopes each key needs. A key that only activates listings needs order:create and order:read.