Operate a deployed agreement by reading its current state, choosing a valid authored input, signing that input, submitting it, and then rereading state and input history. For TypeScript integrations, use the SDK operation loop first. Endpoint paths later in this page use full API paths underDocumentation Index
Fetch the complete documentation index at: https://docs.shodai.network/llms.txt
Use this file to discover all available pages before exploring further.
/v0 for raw HTTP and reference context.
Input submission requires a
walletClient that can sign with the submitting account and a publicClient connected to the agreement chain. The signing wallet must be allowed by the authored input issuer; otherwise the signed input may be well-formed but invalid for the agreement lifecycle. For automated tests that only need signatures, see Create a test-only wallet client.This page shows the API-assisted operation path. The same authorization model is grounded in EIP-712 signed inputs and the onchain execution engine.Applications that need direct onchain operation should refer to the EIP-712 Signing Reference and onchain architecture notes for typed data, contract addresses, and deployment details.
SDK operation loop
Read the agreement and current state
Choose and sign a valid input
issuer before submitting.publicClient must be connected to the target chain/RPC. Low-level signAgreementInputPermit(...) requires an explicit deadline; high-level submitAgreementInputWithPermit(...) defaults to computeDefaultDeadlineSeconds().
Raw operation loop
Read the agreement record
Use
GET /v0/agreements/{id} when your product needs the hosted agreement record and context around it.Read current state
Use Interpret the state against the authored agreement JSON.
GET /v0/agreements/{id}/state to decide which authored inputs are candidates next.Choose a valid authored input
Confirm that the input exists, the current state accepts it, the values match the input schema, and the signer is allowed by the input
issuer.Sign and submit the input
Submit the signed input to The TypeScript client uses a one-hour default permit lifetime through
POST /v0/agreements/{id}/input.computeDefaultDeadlineSeconds(). Use a shorter deadline if your integration requires a tighter replay window, and regenerate the signature whenever the deadline expires.Understand the input record
WhenPOST /v0/agreements/{id}/input succeeds, the API returns an input record.
Read input history
UseGET /v0/agreements/{id}/inputs to inspect recorded submissions. Add ?userId=<id> when you need the optional platform user filter.
Handle state synchronization
You may see an input record with
status: "MINED" before the state view reflects the new lifecycle position. Reread state when your product needs certainty about the current position, and use input history for audit and chronology.Helper boundaries
submitAgreementInputWithPermit(...) signs the input payload and calls client.submitAgreementInput(...) with the resulting signer, deadline, and signature. Use signAgreementInputPermit(...) plus client.submitAgreementInput(...) when your application needs to sign first and submit later.
Why a submission may not move the agreement
When a submission does not advance the agreement, check:- the agreement is in the state that accepts the input
- the submitted
inputIdexists in the authored agreement - the submitted
valuesmatch the input schema - the signer is allowed by the input
issuer - the transition condition references that input from the current state
- the signature has not expired and was generated for this exact payload