Send Transactions
Description: This endpoint submits signed transactions to the blockchain. This endpoint works uniformly for all transaction types prepared using the /prepare-transactions endpoint.
Headers:
x-api-key:YOUR_API_KEYfor API-key auth, orX-Paymentfor x402 retries when sending x402-eligible agentic prepared transactionsContent-Type:application/json
Workflow:
- Prepare Transactions: First, call
/prepare-transactionswith your desired method and parameters - Sign Transactions: Sign each transaction in the returned
transactionsarray using your preferred wallet or signing method - Send Transactions: Submit the signed transactions along with the
txIdto this endpoint
Supported Transaction Types:
This endpoint accepts signed transactions for all methods supported by /prepare-transactions:
newTokenization- Create new tokenized assetsnewSto- Create Security Token OfferingsnewInvest- Make investments in STOsclaimTokens- Claim tokens from completed STOscloseOffer- Close active STOsmintToken- Mint additional tokenswhitelist- Manage address whitelist statusapprove- Approve token spendingburnToken- Burn tokenstransferFrom- Transfer tokens (with approval)transferTo- Transfer tokens from signerdividendDistribution- Distribute dividendsnewTokenizedAgent/agentRegister- Register ERC-8004 agentsagentSetURI,agentSetMetadata,agentSetWallet- Maintain ERC-8004 agent profilesagentGiveFeedback,agentRevokeFeedback,agentAppendFeedbackResponse- Manage reputation entriesagentCreateToken,agentMintToken,agentBurnToken,agentTransferToken,agentTransferFromToken,agentApproveToken- Manage agent ERC-20 tokens
x402 can be used only for x402-eligible agentic prepared transactions. Do not mix x402-eligible and API-key-only transactions in the same send batch.
/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 byexecutionMode, 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 ofsignedTransactions,txHash, ortransactions— never two. Abrickken-relayedsend requires x402 payment; API keys are not accepted on that path.
Request Body
Brickken-relayed (recommended for agentic methods)
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 withexecutionMode: "client-broadcast", sign and broadcast the transaction with your own infrastructure, then report the hash:
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- Prepare: call
/prepare-transactionswith your method, parameters, andsignerAddress. - Sign: sign each transaction in the returned
transactionsarray with your wallet. - Send: submit
signedTransactions+txIdto this endpoint (withX-PAYMENTfor x402 methods).
- Prepare (free): call
/prepare-transactions(or an/x402/...facade) withexecutionMode: "brickken-relayed"and omitsignerAddress. - Send + pay: submit
transactions+txId, retry withX-PAYMENT. Brickken signs and broadcasts; the payment settles only after on-chain confirmation.
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
txIdmatches the one received from/prepare-transactions. - In
client-signedmode, use secure signing methods and never share or expose private keys in client-side code. - In
brickken-relayedmode you sign only the x402 payment authorization; never resubmit or re-pay atxIdonce an operation hash exists — poll status instead.
Authorizations
Body
- client-signed — you sign, Brickken broadcasts
- client-broadcast — you sign and broadcast, then confirm
- brickken-relayed — Brickken signs and broadcasts
Three mutually exclusive shapes, one per executionMode. Send exactly one of them.
Must match the format of signedTransactions: both strings, or both arrays of equal length.
"0x11769b5c2028a8ed0a3bdc7599e244aee68e2cae80261d8954e44c3b5cb621a4"
Signed transaction hex string(s) starting with 0x. Never objects.
"0x02f8b1018203e8843b9aca00850ba43b7400825208..."