Skip to main content
At the end of this page, you will have set up an Errand. On the wire you create an IPA (the durable intent record) that returns 202 Accepted with a preflight_workflow_id, poll it through the lifecycle, and approve it — landing the IPA record in the approved state, ready for the agent to begin executing the Errand. The create call: An Errand is the durable contract between a user and an agent (an Envoy). It captures the intent — what the user wants, what the agent is allowed to do, for how long, and under what constraints — and follows the Intent → Authorization → Vigilance arc. On the wire, an Errand is created and tracked as an IPA record. Once approved, that record drives the full Errand workflow.
This quickstart uses the current IPA model — preflight_workflow_id, originating_chat_id, originating_agent_task_id, and the originating_agent_task / executing_agent_task expansions. Treat this quickstart as the source of truth for IPA request and response shapes.

Prerequisites

  • A Sumvin-verified user with a deployed Safe. If you don’t have one, run the stand up an account quickstart first.
  • A that grants the scopes this Errand needs. See Stamped Mandates for the mint flow and scopes for the full catalog. The create call does not name a mandate — the Errand’s authorisation is settled from the scopes on the caller’s own Stamped Mandate, and what may be spent is settled at the draw.
  • A Platform API JWT. See authentication.
1

Mint a Stamped Mandate for the Errand

Errands need scopes like sr:us:pint:perpetual:search plus any downstream action scopes (for example sr:us:pint:spend:execute if the Errand will authorise purchases).The Stamped Mandate mint flow is covered in full at Stamped Mandates. You never pass its URI to POST /v0/user/ipa — the create call carries no mandate reference.
2

Create the IPA

Post the user’s intent, autonomy preferences, and constraints. Include the Idempotency-Key header so retries do not create duplicate records.
Using TanStack Query? useCreateIPA invalidates the IPA list and agent-task queries on success. To forward an Idempotency-Key header, see the mutation patterns page for the recommended wrapper shape.
3

Inspect the 202 Accepted response

Response: 202 Accepted
The preflight_workflow_id points to the workflow run that parses and qualifies the intent. The IPA status starts as qualifying while preflight runs.
4

Poll the IPA status

Fetch the IPA until it transitions out of qualifying. Use the originating_agent_task expansion to see the preflight agent task in the same response.
Response: 200 OK
The full set of IPA statuses:
  • qualifying — preflight is validating the intent and scopes
  • searching — the agent is actively crawling for candidates
  • validating — candidates are being scored against constraints
  • pending_clarification — the agent needs more information from the user
  • pending_approval — approved candidate(s) awaiting user sign-off
  • approved — the user approved; the executing agent may proceed
  • monitoring — watching for trigger conditions (price, availability)
  • executing — the purchase is being executed
  • completed — the IPA fulfilled its intent
  • failed — terminal failure
  • expired — lifetime elapsed without fulfilment
  • cancelled — the user cancelled
5

Respond to clarifications (if needed)

If the agent lands in pending_clarification, answer the outstanding questions. The IPA returns to qualifying while the agent incorporates the answers.PUT /v0/user/ipa/{ipa_id}/answers — Submit clarification answers.
Response: 200 OK with intent.status: "qualifying".
6

Approve the IPA

This is the working artefact. Once the IPA record is pending_approval, approve it — the executing agent (the Envoy) can then begin searching under the terms you set.Approving authorises spending, so it is signed by the account holder rather than simply asserted. Fetch the prepared payload with ?expand=mandate, sign intent.approval_payload with the wallet on the account (eth_signTypedData_v4), and send the signature with the decision. The spend ceiling, conditions and deadline are read from that signed payload, so an approval always means exactly what was signed.
The @sumvin/api-hooks package does not expose the signed approval yet — useApproveIPA still submits a decision without a signature, so it cannot approve. Call the endpoint directly, as above, until the hook is updated.
Using TanStack Query? Approving changes the Errand, so invalidate both ipas.all and ipas.detail(id) afterwards — see invalidation strategy.
Response: 200 OK
The Errand is live. The executing agent has begun work under the scopes, constraints, and autonomy level you defined — and the user can revoke at any time.
7

Cancel at any time

Users can cancel an Errand at any non-terminal state. The executing agent halts and the IPA record transitions to cancelled.DELETE /v0/user/ipa/{ipa_id} — Cancel an Errand.
Response: 200 OK with intent.status: "cancelled".

What’s next