Request x402 payment requirements
Send the final judgement body once to receive the exact network, asset, amount, escrow, and request-scoped authorization to sign.
/v1/x402/requestsA 402 response is the expected first step. Takusen returns an x402 v2 PAYMENT-REQUIRED header and the same document as JSON. Keep the serialized request body: the challenge is bound to it and expires after ten minutes.
Parameters
settlementDomainstringbodyrequiredA healthy domainId returned by GET /v1/chain.
promptstringbodyrequiredThe complete question, relevant context, and explicit resolution rule.
outputTypeboolean | score | choice | private_hashbodyrequiredThe typed result contract used for validation and settlement.
outputSchema{ minimum, maximum, choices[] }bodyrequiredRequest-specific bounds and ordered human meanings. Integer ranges must be within 0–100; choices contain 2–26 unique labels and encode as A onward.
modelsstring[]bodyrequiredOne or more active model IDs returned by GET /v1/models.
spendLimitMicrosint64bodyrequiredMaximum all-in spend in μUSDC. The payer must already have this amount available in the selected domain.
timeLimitSecondsintbodyrequiredExecution deadline from 5 through 600 seconds.
executionQuorumintbodyrequiredAgreement threshold shown to the consumer; lifecycle finality remains validator-authorized.
visibilitypublicbodyrequiredUse public for sessionless x402 integrations so the result and stream remain readable without application login.
Access
Consumer notes
- This is prepaid x402: the signature reserves existing domain credits; it does not transfer USDC during each API call.
- Fund the payer once before using this flow. The challenge reports the selected USDC asset, escrow, and supported deposit mechanisms.
- Smart-contract applications can register extensions.takusen.binding before submitting PAYMENT-SIGNATURE, guaranteeing that binding precedes execution without making result reads private.
- Serialize the body once and reuse it for the signed submission. Do not rebuild or mutate it between calls.
On-chain identifiers and result discovery
GET /v1/requests/{id} returns the API UUID together with onchainRequestId, settlementDomain, chainId, escrow, resultsContract, verifier, protocolVersion, modelSetHash, schemaHash, outputSchema, and onchainModels. Every onchainModels entry pairs the public model name with its bytes32 onchainModelId. Integrators do not need to reproduce Takusen's SHA-256 identifier convention before reading ITakusenResults.
GET /v1/chain is the governed deployment registry. The loader requires a non-zero resultsContract and protocolVersion and verifies protocolVersion() against the live contract before exposing a domain; the API returns those verified deployment fields rather than assuming escrow or version 2. Select an active, healthy domain, call its resultsContract through ITakusenResults, wait for FINALIZED unless using a contract-owned irreversible early policy, verify the complete ordered model set, and decode only SUCCESS results with TakusenOutput.