Submit or track a signed transaction

Submit or track a signed transaction.

Credential: Customer session or partner secret

Before you call

• A customer session, or an owning partner server credential without Origin.
• Use the original preparationId and the customer’s registered wallet.
• Keep the signed bytes and any known hashes if you need to recover an uncertain submission.
• Set an Idempotency-Key and reuse it for an identical retry.

Submits a signed transaction, or reports a transaction that your wallet already sent, for a prepared transaction. Send the preparationId, exactly one of signedTransaction or transactionHash, and an Idempotency-Key. Use the owning customer session, or an authorized partner server credential without an Origin header.

Signed transactions. signedTransaction must be a serialized EIP-1559 transaction from the registered wallet. Its chain, destination, calldata and zero value must match the prepared transaction. The wallet fills in the nonce, gas and fees, so use its pending nonce. A signature over a UserOperation is not a serialized transaction. Before it broadcasts, Sinbad checks the nonce and the native balance, then simulates the call. A native gas shortage returns 400 INSUFFICIENT_BALANCE with details.kind: NATIVE_GAS, asset: POL, the chainId, and the required, current and missing amounts in wei and in POL. A stale nonce returns 409 CONFLICT first. A failed simulation or a temporary network failure can return a generic 503 UPSTREAM_ERROR: check the allowance, the balance and the trade state before you retry identical bytes.

Transactions sent elsewhere. For a transaction executed outside Sinbad, including smart-account execution, report the included blockchain transactionHash, not a userOpHash. Partners arrange their own wallet execution and gas funding or sponsorship. An escrow hash report can start tracking before a receipt is available, and returns 202 with PENDING_CONFIRMATION. A hash report for a trade action that is unavailable, or below the required confirmation depth, can return 502 UPSTREAM_ERROR: retry the same report, and do not broadcast again. The evidence must match the prepared escrow or action and its participants.

Idempotency. An Idempotency-Key contains 8 to 128 letters, digits, underscores or hyphens. It binds the prepared transaction and its hash for 30 days. Reusing a bound key with a different prepared transaction or hash returns 409 CONFLICT. Accepted signed transactions, and transactions for other purposes, stay bound to their hash. After a definite failure, request a new prepared transaction if the step is still allowed. Track a pending or uncertain transaction, and never replace one just because it is slow.

Correcting a wrong escrow hash. If you reported the wrong hash for an escrow transaction that your wallet sent, report the correct included transactionHash for the same preparationId with a new key. Sinbad accepts the correction only after a successful receipt at the required confirmation depth proves that exact checkout. Unavailable or unconfirmed evidence returns 502, invalid evidence cannot replace tracking, and confirmed tracking cannot be replaced. Original reports that Sinbad already accepted then return the current result.

After a 202. A 202 means tracking has started, not that funding is confirmed. Poll transaction.status and the breakdown. trade stays null until funding is confirmed. If wallet escrow tracking stays unresolved for 24 hours, it becomes REVIEW_REQUIRED, and the customer’s open trade stays held. Once Sinbad confirms on chain that an unfunded breakdown expired, tracking can end as EXPIRED. Late verified evidence can still reconcile wallet escrow tracking that is not confirmed. Signing expiry does not stop confirmation tracking. Trade action transactions have expiresAt: null, and approvals and escrow transactions keep the breakdown’s deadline.

Confirm with Sinbad that this endpoint is enabled in your environment.

Errors