Stage 1 of the two-stage enrollment flow — returns a signable session-key message for the user to sign in their wallet.
strategyId belongs to
your tenant, peeks the user’s next available account index, resolves a pooled
KMS agent for them, and returns the merkle root the user must sign in their
wallet plus the round-trip values (flowId, accountIndex, agentAddress)
that stage 2 (POST /v2/enroll) will need.
x-api-key header (required)enroll:writeflowId is the idempotency anchor for the matching POST /v2/enroll
call — it’s valid for 24 hours and lets the server replay a previously-completed
enrollment if the same flowId is submitted twice.
The accountIndex is peeked, not reserved: repeated stage-1 calls for the
same user return the same candidate index, and the index only advances when stage
2 commits successfully. This means retries, abandoned flows, and testing loops
do not burn account indices.
The chainIds array is validated against the deployment’s configured RPC URLs
(JSON_RPC_URL_<chainId> env vars). Unknown or not-deployed chains are rejected
at this stage with 400 before any enrollment state is created.
Common error responses:
400 when the request body is invalid, the strategyId doesn’t exist or
belongs to a different tenant, or any chainIds entry is not configured for
this deployment401 when x-api-key header is missing or the key is invalid403 when the API key lacks the enroll:write scope500 on unexpected server errors