marketplace

POST /v1/marketplace/orders/{sale_id}/requirements

The buyer's brief — and the thing that starts the delivery clock.

All marketplace endpoints

Authentication

Send an API key as a bearer token. This endpoint does not state a specific permission in the specification, so give your key the least it needs and check the response rather than assuming.

This endpoint takes no organisation id. Your key already identifies the organisation it belongs to, and the response is scoped to it.

Try it

Replace anything in angle brackets with your own values, and the key placeholder with a key from your dashboard.

curl -X POST https://api.zinndigital.com/v1/marketplace/orders/{sale_id}/requirements \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "requirements": <object> }'

Signed in? The API console in your dashboard fills in your real organisation id and your own key, and runs the request against the live API so you can see the actual response. Open this endpoint in the API console

Details

docs/147 §2. A paid order used to arrive carrying a package name and nothing else: the seller could not start, the clock was running, and there was no channel to ask. **Submitting is what starts the delivery clock.** Until this call the seller's deadline does not exist, so the days a buyer spends writing their brief are never billed against the seller's deadline and a seller is never late for work they could not begin. The questions come from the order's own frozen `requirements_schema` — a snapshot taken at purchase, so a seller who rewrites their questions tomorrow cannot change what this buyer was asked. Buyer only. A seller gets a 404, the same way acceptance is the buyer's act alone.

Parameters

NameTypeRequiredWhat it is
sale_id (path)stringYes

Request body

NameTypeRequiredWhat it is
requirementsobjectYesAnswer per question key, validated against the frozen schema.

Response

NameTypeRequiredWhat it is
sale_idstringYes
statestringYes
archetypeMarketplaceOrderArchetypeYesHow this order behaves. Adding a CATEGORY is configuration; adding an ARCHETYPE is a build. Every order-side decision — whether a delivery clock exists, whether auto-accept appl…
listing_titlestringNo
package_namestringNo
turnMarketplaceOrderTurnYesWhose move it is. `staff` is a real answer, not a fallback: a disputed order is genuinely waiting on us, and telling a buyer "waiting for the seller" while a moderator holds it…
waiting_onMarketplaceOrderWaitingOnYesWhat the order is waiting FOR — the half that makes `turn` actionable.
is_yoursbooleanNoWhether the caller is the party being waited on.
is_buyerbooleanYes
deadlinestringNoThe clock that is actually running, or null when none is.
pausedbooleanNoA clock EXISTS but is stopped — the revision pause. Distinct from a null deadline, which also covers an order that never had a clock at all.
overduebooleanNoNever true while `delivery_due_at` is null: null means the clock has not started, which is exactly the state of an order whose buyer has not written their brief yet.
handover_confirmedintegerNo
handover_requiredintegerNo
outstandingstring[]NoQuestion keys the buyer still owes.
revisions_usedintegerNo
revisions_includedintegerNo
delivery_due_atstringNo
currencystringNo
gross_minorintegerNoInteger minor units. Money is never a float.
commission_minorintegerNoThe platform's commission, as its own figure. Present for the SELLER and null for the buyer — to a buyer the price is the price. The platform is merchant of record on every mark…
vendor_net_minorintegerNoWhat we owe the seller — a trade payable, not money held on trust.
requirements_schemaobject[]NoThe questions AS ASKED, frozen at purchase. A seller who rewrites their questions tomorrow cannot change what this buyer was asked.
requirementsobjectNoThe buyer's answers, in the same `{key: {v: …}}` envelope.
requirements_submitted_atstringNo
handover_itemsMarketplaceHandoverItem[]No
last_revision_reasonstringNo

Errors this endpoint can return

401 · 404 · 422