Read a signing request
Returns one `TxRequest` by id, so either kind of caller can poll the status of a request they created. A request owned by another user answers with the same 404 as a request that does not exist, and the two response bodies are identical — a caller cannot probe for the existence of someone else's request.
Returns one TxRequest by id, so either kind of caller can poll the status of a request they created. A request owned by another user answers with the same 404 as a request that does not exist, and the two response bodies are identical — a caller cannot probe for the existence of someone else's request.
Path Parameters
The request id, as returned by the create route or a tool.
Response Body
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/tx/string"{ "id": "string", "ownerId": "string", "chainSlug": "ethereum", "unsignedTx": { "chainId": 0, "to": "string", "data": "string", "value": "string" }, "summary": [ "string" ], "simulation": { "ok": true, "balanceChanges": [ { "token": "string", "symbol": "string", "delta": "string" } ], "events": [ "string" ] }, "fees": [ { "label": "string", "bps": 0 } ], "delivery": "dashboard", "status": "pending", "txHash": "string", "dependsOn": "string", "createdAt": "string", "expiresAt": "string"}Create a signing request POST
Persists an **unsigned** transaction and returns it as a `TxRequest`. The server does not sign and does not broadcast: the caller signs with its own wallet, then reports the hash to `POST /tx-requests/{id}/submitted`. Which of the two signing paths applies is decided by the caller's bearer, not by the request — a Privy access token yields `delivery: "dashboard"` (the dashboard's sign-request modal picks it up) and an `sk-` API key yields `delivery: "unsigned"` (nothing is queued for the dashboard). The response carries the decoded plain-English `summary` and the `simulation` so the caller can show the user what they are approving before signing.
Report a signed transaction hash POST
Records the hash of a transaction the **caller** signed, and moves the request to `submitted`. This is how an external agent that signed with its own wallet keeps launch status and the Onchain page accurate; the dashboard's sign-request modal posts here after the user's Privy wallet returns a hash. The worker then confirms the receipt onchain and moves the request to `confirmed` or `failed`. Reporting a hash twice is accepted and keeps the first one — a client that retried after a timeout must not rewrite the row. A request owned by another user answers with the same 404 as one that does not exist.