Skip to main content
Use direct-claim.v1 when participants should take available capacity in server order. Event registration, appointment booking, and fixed-capacity access are common examples.

​
Rules

The creator defines: With confirmation: none, an accepted claim commits immediately. With confirmation: creator, the first valid claimant holds capacity while the creator approves or declines. This is the request-to-book shape.

​
Participant flow

  1. Read the published market and confirm its capacity, terms, and funding mode.
  2. Call submit_direct_claim or POST /v1/markets/{marketId}/direct-claims.
  3. If confirmation is required, act before the hold expires.
  4. Recover the current commitment through get_my_market_outcome or /v1/markets/{marketId}/my-outcome.
Claims may omit expectedVersion. Ambient then orders concurrent claims by authoritative server arrival. When a held claim is declined or expires, its capacity becomes available again. When claimsCloseAt is present, publication schedules a durable close and the kernel rejects claims exactly at or after the cutoff even if the worker is delayed. The creator can also call close_direct_claims or POST /v1/markets/{marketId}/claim-closures to stop future claims while preserving commitments already accepted. This is distinct from canceling an unparticipated market.

​
Private handoff data

A market can publish a fulfillment request schema and accepted delivery transports. The participant then includes a private request and delivery endpoint with the claim. Ambient stores that handoff in the commitment and creator record but does not invoke the endpoint or perform fulfillment.

​
Disclosure and record

The public market shows remaining allocation state without exposing private handoff data or participant commitments. The participant sees only its own outcome. The creator record includes the ordered claim and commitment history, and Ambient can independently replay this mechanism’s stored state. See MCP tools and the HTTP API for exact fields.