Skip to main content
POST
Submit Signed Transactions
Confirms or broadcasts a prepared transaction. It works uniformly for every transaction type produced by /prepare-transactions. For x402-eligible agentic methods, authenticate with either x-api-key or an x402 payment. To pay, omit x-api-key, read the PAYMENT-REQUIRED header from the 402 response, then retry with X-PAYMENT.

The three execution modes

Which shape you send is decided at prepare time by executionMode, and the send must match — a mismatch is rejected with Prepared transaction was not created for … execution. client-broadcast is for teams that already own their broadcasting: you sign and submit the transaction to the chain yourself, then tell Brickken the resulting hash so it can reconcile its record. It works for Dapp API methods as well as agentic ones. brickken-relayed is the only mode restricted to x402-eligible agentic methods.

Parameters

[!IMPORTANT] Send exactly one of signedTransactions, txHash, or transactions — never two. A brickken-relayed send requires x402 payment; API keys are not accepted on that path.

Request Body

Pay with the X-PAYMENT header. Brickken verifies the payment, signs with its relayer, and broadcasts. The payment is settled only after the operation confirms on-chain.

Legacy Format (Single Transaction)

Array Format (Multiple Transactions)

Client-broadcast (you already sent it)

Prepare with executionMode: "client-broadcast", sign and broadcast the transaction with your own infrastructure, then report the hash:
Exactly one txId and one txHash — arrays are rejected. Brickken reconciles the hash against the prepared record and updates its own state, so the transaction shows up in get-transaction-status and in the dApp like any other. Resubmitting the same pair is idempotent.

Response

Success Response

Error Response

Workflow

Client-signed
  1. Prepare: call /prepare-transactions with your method, parameters, and signerAddress.
  2. Sign: sign each transaction in the returned transactions array with your wallet.
  3. Send: submit signedTransactions + txId to this endpoint (with X-PAYMENT for x402 methods).
Brickken-relayed
  1. Prepare (free): call /prepare-transactions (or an /x402/... facade) with executionMode: "brickken-relayed" and omit signerAddress.
  2. Send + pay: submit transactions + txId, retry with X-PAYMENT. Brickken signs and broadcasts; the payment settles only after on-chain confirmation.
A relayed send returns 200 with status: "confirmed" once the receipt is in, or 202 with status: "pending" if the operation was broadcast but not yet confirmed — in which case poll /get-transaction-status rather than resubmitting.

Supported Transaction Types

This endpoint accepts transactions for all methods supported by /prepare-transactions. Dapp (API key): newTokenization, newSto, newInvest, claimTokens, closeOffer, mintToken, whitelist, approve, burnToken, transferFrom, transferTo, dividendDistribution. Agentic (x402-eligible): agentRegister, agentSetURI, agentSetMetadata, agentSetWallet, agentTransferOwnership, agentGiveFeedback, agentRevokeFeedback, agentAppendFeedbackResponse, agentCreateToken, agentMintToken, agentBurnToken, agentTransferToken, agentTransferFromToken, agentApproveToken (and the legacy newTokenizedAgent alias).

Transaction Status

After submitting transactions, check their status using the /get-transaction-status endpoint with the returned transaction hash (hash) or the original transaction ID (txId) from /prepare-transactions. For brickken-relayed transactions, no API key is required to poll status. For x402 sends, the batch must contain only x402-eligible agentic prepared transactions and all transactions must be on the same chain.

Security Notes

  • Always verify transaction details (chain, recipient, token, amount, and the quoted USDC price) before paying or signing.
  • Ensure the txId matches the one received from /prepare-transactions.
  • In client-signed mode, use secure signing methods and never share or expose private keys in client-side code.
  • In brickken-relayed mode you sign only the x402 payment authorization; never resubmit or re-pay a txId once an operation hash exists — poll status instead.

Authorizations

x-api-key
string
header
required

Body

application/json

Three mutually exclusive shapes, one per executionMode. Send exactly one of them.

txId
required

Must match the format of signedTransactions: both strings, or both arrays of equal length.

Example:

"0x11769b5c2028a8ed0a3bdc7599e244aee68e2cae80261d8954e44c3b5cb621a4"

signedTransactions
required

Signed transaction hex string(s) starting with 0x. Never objects.

Example:

"0x02f8b1018203e8843b9aca00850ba43b7400825208..."

Response

Successful response

txHash
string

Transaction hash of the submitted transaction

Example:

"0x1234567890abcdef..."

status
string

Transaction status

Example:

"pending"