Operations and Transaction Intents
Two resources cover everything asynchronous or wallet-signed in API v2:- An operation is long-running server work you poll for a terminal state.
- A transaction intent is a Solana transaction that Blank prepared for a specific wallet, which that wallet must sign before Blank will broadcast it.
Operations
Operations are account-scoped: a key can only read operations owned by its own Blank account. Unknown or foreign IDs return
404 operation_not_found.
Fields
queued and running responses carry Retry-After: 2. Honour it instead of tight polling.
Polling
failed operation carries the full Problem Details in error, including the code and the requestId of the failure. Log both.
Rather than polling at all, subscribe to build.blank.operation.failed.v1 and the completion events you care about. See Webhooks.
Transaction intents
Intents are account-scoped in the same way. The public contract exposes retrieval and signed submission; an intent is prepared by the Blank flow that needs a wallet signature, and you receive its
intentId from that flow.
Fields
Lifecycle
prepared— Blank has built the transaction and is waiting for a signature.submitted— the signature verified and the transaction is durably queued for broadcast. The response carriesRetry-After: 2.confirmed— the transaction landed.transactionSignatureis populated.expired— the blockhash window closed before a valid submission arrived.failed— broadcast or confirmation failed.errorexplains why.
Signing and submitting
If-Match: "<version>"— the intent version you readIdempotency-Key— a durable key you should generate and persist yourself
202 response includes Location pointing at the intent, ETag with the new version, and Retry-After: 2.
Raw HTTP:
Reconciling an uncertain submission
A202 means the transaction is durably queued, not that it landed. Never assume an outcome from a dropped connection.
- Retry the submission with the same
Idempotency-Key. A completed attempt replays withIdempotent-Replayed: true; an in-flight attempt returns409 idempotency_request_in_progresswithRetry-After: 1. - Poll
getTransactionIntentuntilstatusreachesconfirmed,failed, orexpired, honouringRetry-After. - On
confirmed, recordtransactionSignature. Onfailed, readerror.code. Onexpired, request a fresh intent — a signature cannot be reused across intents.
TransactionIntent.error.code is a closed contract: solana_transaction_failed, transaction_intent_invalid_state, transaction_intent_expired, transaction_intent_broadcast_exhausted, solana_blockhash_expired, or solana_signature_mismatch. See Transaction-intent result codes for the action associated with each one.
Submission errors
Shared errors also apply:
401 invalid_api_key, 403 insufficient_scope, 409 idempotency_key_reused, 409 idempotency_request_in_progress, 429 rate_limit_exceeded. See Errors and Conventions.