> ## Documentation Index > Fetch the complete documentation index at: https://docs.brickken.com/llms.txt > Use this file to discover all available pages before exploring further. # 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_KEY` for API-key auth, or `X-Payment` for x402 retries when sending x402-eligible agentic prepared transactions - `Content-Type`: `application/json` **Workflow:** 1. **Prepare Transactions**: First, call `/prepare-transactions` with your desired method and parameters 2. **Sign Transactions**: Sign each transaction in the returned `transactions` array using your preferred wallet or signing method 3. **Send Transactions**: Submit the signed transactions along with the `txId` to this endpoint **Supported Transaction Types:** This endpoint accepts signed transactions for all methods supported by `/prepare-transactions`: - `newTokenization` - Create new tokenized assets - `newSto` - Create Security Token Offerings - `newInvest` - Make investments in STOs - `claimTokens` - Claim tokens from completed STOs - `closeOffer` - Close active STOs - `mintToken` - Mint additional tokens - `whitelist` - Manage address whitelist status - `approve` - Approve token spending - `burnToken` - Burn tokens - `transferFrom` - Transfer tokens (with approval) - `transferTo` - Transfer tokens from signer - `dividendDistribution` - Distribute dividends - `newTokenizedAgent` / `agentRegister` - Register ERC-8004 agents - `agentSetURI`, `agentSetMetadata`, `agentSetWallet` - Maintain ERC-8004 agent profiles - `agentGiveFeedback`, `agentRevokeFeedback`, `agentAppendFeedbackResponse` - Manage reputation entries - `agentCreateToken`, `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. 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`. | `executionMode` | Who signs | Who broadcasts | You send | Cost split | | --------------------------- | ------------------ | -------------- | ----------------------------- | -------------------------------- | | `client-signed` *(default)* | You | Brickken | `txId` + `signedTransactions` | half at prepare, half at send | | `client-broadcast` | You | **You** | `txId` + `txHash` | half at prepare, half at send | | `brickken-relayed` | Brickken's relayer | Brickken | `txId` + `transactions` | free prepare, full price at send | **`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 | Parameter | Type | Required | Description | | -------------------- | ------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------ | | `txId` | string \| string\[] | Yes | Transaction ID(s) from the prepare response. An array only in client-signed mode; a single string otherwise. | | `signedTransactions` | string \| string\[] | client-signed | Signed transaction hex string(s) starting with `0x`. A single string (legacy) or an array matching the format of `txId`. | | `txHash` | string | client-broadcast | Hash of the transaction you already broadcast. Exactly one, paired with exactly one `txId`. | | `transactions` | object\[] | brickken-relayed | Exactly one prepared call `{ to, data, value }` returned by prepare. | > \[!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 ### Brickken-relayed (recommended for agentic methods) ```json theme={null} { "txId": "0x11769b5c2028a8ed0a3bdc7599e244aee68e2cae80261d8954e44c3b5cb621a4", "transactions": [ { "to": "0xRegistry", "data": "0x...", "value": "0x0" } ] } ``` 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) ```json theme={null} { "signedTransactions": "0x02f8b1018203e8843b9aca00850ba43b740082520894742d35cc6634c0532925a3b8d4c9db96c4b4d8b80b844a9059cbb000000000000000000000000456789abcdef...", "txId": "0x11769b5c2028a8ed0a3bdc7599e244aee68e2cae80261d8954e44c3b5cb621a4" } ``` ### Array Format (Multiple Transactions) ```json theme={null} { "signedTransactions": [ "0x02f8b1018203e8843b9aca00850ba43b740082520894742d35cc6634c0532925a3b8d4c9db96c4b4d8b80b844a9059cbb000000000000000000000000456789abcdef..." ], "txId": [ "0x11769b5c2028a8ed0a3bdc7599e244aee68e2cae80261d8954e44c3b5cb621a4" ] } ``` ### Client-broadcast (you already sent it) Prepare with `executionMode: "client-broadcast"`, sign and broadcast the transaction with your own infrastructure, then report the hash: ```json theme={null} { "txId": "0x11769b5c2028a8ed0a3bdc7599e244aee68e2cae80261d8954e44c3b5cb621a4", "txHash": "0x9f2c1f4b6e8a3d5c7b0e1a2d4f6c8b0a3e5d7c9f1b3a5c7e9d1f3b5a7c9e1d3f" } ``` 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 ```json theme={null} { "txHash": "0x1234567890abcdef...", "status": "pending" } ``` ### Error Response ```json theme={null} { "error": { "code": "INVALID_SIGNATURE", "message": "Transaction signature is invalid", "details": { "transactionIndex": 0, "expectedSigner": "0x742d35Cc6634C0532925a3b8D4C9db96c4b4d8b", "actualSigner": "0x..." } } } ``` ## 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. ## OpenAPI ````yaml POST /send-transactions openapi: 3.1.0 info: title: Brickken API V2 description: >- Welcome to the Brickken API documentation. This API allows customers to create and manage tokenization processes, including creating new tokenizations, minting/burning/transferring tokens, whitelisting users, manage tokens approvals. This documentation provides detailed information on how to use the API, including the necessary endpoints, request formats, and expected responses.
**Authentication**All API requests require an API key for authentication. Include your API key in the `x-api-key` header of each request:
```
      x-api-key: YOUR_API_KEY
    ```
Ensure that your API key is kept secure and not shared publicly. A common parameter for all requests is the `signerAddress`. Such address MUST be whitelisted in our factory. To whitelist an address and/or request an API key either for sandbox/production environment please contact with: tech@brickken.com. Once a `signerAddress` performs a `newTokenization` we refer to that address as the tokenizer. The tokenizer will be the only one allowed to mint such token, distribute dividends on such token and whitelist/blacklist investors of such token. Regarding actions like transferring tokens or burning tokens, the `signerAddress` can be any user and not only the tokenizer.
**Supported Networks & Addresses**
Sepolia (sandbox environment only)
```
      Chain Id: "aa36a7"
      Factory Address: "0x933ABAA95a7Fd0Bc683bDe2adB89f4C5EA64897b"
      BKN Address: "0x97a13487f889dc770Ac925Be2d3b6c833FA7746a"
      USDT Address: "0x28d2B01854D0aBec267a3DDcad9163580E6E8604"
      USDC Address: "0xb10cE8e28aEb1ae27b968Fb3bfed2FD7dd52daCb"
    ```
Base Sepolia (sandbox / testing)
```
      Chain Id: "84532" (hex "14a34")
      x402 USDC (Circle, EIP-3009): "0x036CbD53842c5426634e7929541eC2318f3dCF7e"
      ERC-8004 Identity Registry: "0x8004A818BFB912233c491871b3d84c89A494BD9e"
      ERC-8004 Reputation Registry: "0x8004B663056A597Dffe9eCcC1965A193B7388713"
    ```
Ethereum mainnet (production environment only)
```
      Chain Id: "1"
      Factory Address: "0x91af681C85Ca98Efc5D69C1B62E6F435030969Db"
      BKN Address: "0x0A638F07ACc6969abF392bB009f216D22aDEa36d"
      USDT Address: "0xdac17f958d2ee523a2206206994597c13d831ec7"
      USDC Address: "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48"
    ```
Base mainnet (production environment only)
```
      Chain Id: "2105"
      Factory Address: "0x278D7bdc2451B0Fa4087A68ce084a86cB91D4d83"
      BKN Address: "0xddB293BB5C5258F7484A94a0fBd5c8B2F6E4e376"
      USDT Address: N/A
      USDC Address: "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913"
    ```
BNB Smart Chain mainnet (production environment only)
```
      Chain Id: "38"
      Factory Address: "0xCe4529Fe88df480BD777d3e32dfD7032e6C685ff"
      BKN Address: "0x0e28bC9B03971E95acF9ae1326E51ecF9C55B498"
      USDT Address: "0x55d398326f99059fF775485246999027B3197955"
      USDC Address: "0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580d"
    ```
Avalance C Chain mainnet (production environment only)
```
      Chain Id: "a86a"
      Factory Address: "0xc6c230FA8F40022dE997727436Fae01caAbcDe61"
      BKN Address: "0xd44E4Dc8bdF7C1c62CfDBb182022097BA42Ac6bC"
      USDT Address: "0x9702230A8Ea53601f5cD2dc00fDBc13d4dF4A8c7"
      USDC Address: "0xB97EF9Ef8734C71904D8002F8b6Bc66Dd9c48a6E"
    ```
**Usage Workflow**
1. **Prepare Transactions:**- Use the `POST /prepare-transactions` endpoint with the desired method (e.g., `newTokenization`, `mintToken`, etc...) to prepare the transaction(s). - The response will include an array of unsigned transactions that needs to be signed.
**Example Of An Endpoint Response:**```json { "transactions": [ { "from": "0xSignerAddress", "to": "0xTargetAddress", "value": { "type": "BigNumber", "hex": "0x00" }, "nonce": 1, "chainId": 11155111, "data": "0x...", "type": 2, "maxPriorityFeePerGas": { "type": "BigNumber", "hex": "0x..." }, "maxFeePerGas": { "type": "BigNumber", "hex": "0x..." }, "gasLimit": { "type": "BigNumber", "hex": "0x..." } } ] } ```
2. **Sign the Transactions:**- Use your preferred method or wallet to sign the transaction data provided in the response. - Ensure that the signer address matches the `signerAddress` provided in the initial request.
**Example Of signing a transaction with typescript and `ethers-js`:**```typescript const tx = {...} // One of the object in the array returned by the `/prepare-transactions` endpoint const privateKey = process.env.PRIVATE_KEY; const wallet = new ethers.Wallet(privateKey); const signedTx = await wallet.signTransaction(tx); console.log('Signed Transaction:', signedTx); ```
**NOTE:** Be sure to have enough funds in the signer wallet to cover for the transaction cost
3. **Submit Signed Transactions:**- Use the `POST /send-transactions` endpoint to submit the signed transaction(s) along with the required parameters. - The API will process the transactions, send them to the blockchain, and update the Brickken database accordingly.
4. **Check Transaction Status:**- Use the `GET /get-transaction-status` endpoint to check the status of your transaction. - Provide either the on-chain transaction hash (`hash`) or the internal transaction ID (`txId`) to retrieve the status.
**Environments**The API is available in several environments for testing and production purposes:- Sandbox: `https://api.sandbox.brickken.com/` - Master (Production): `https://api.brickken.com/`
The API also exposes x402scan discovery facade endpoints under /x402/... The public discovery target is https://api.brickken.com, with /.well-known/x402 returning resource URLs and /openapi.json returning the generated OpenAPI 3.1 document. version: 2.0.0 servers: - url: https://api.sandbox.brickken.com description: Sandbox Environment - url: https://api.brickken.com description: Production Environment security: - apiKeyAuth: [] paths: /send-transactions: post: tags: - Endpoints summary: Submit Signed Transactions description: >- **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_KEY` for API-key auth, or `X-Payment` for x402 retries when sending x402-eligible agentic prepared transactions - `Content-Type`: `application/json` **Workflow:** 1. **Prepare Transactions**: First, call `/prepare-transactions` with your desired method and parameters 2. **Sign Transactions**: Sign each transaction in the returned `transactions` array using your preferred wallet or signing method 3. **Send Transactions**: Submit the signed transactions along with the `txId` to this endpoint **Supported Transaction Types:** This endpoint accepts signed transactions for all methods supported by `/prepare-transactions`: - `newTokenization` - Create new tokenized assets - `newSto` - Create Security Token Offerings - `newInvest` - Make investments in STOs - `claimTokens` - Claim tokens from completed STOs - `closeOffer` - Close active STOs - `mintToken` - Mint additional tokens - `whitelist` - Manage address whitelist status - `approve` - Approve token spending - `burnToken` - Burn tokens - `transferFrom` - Transfer tokens (with approval) - `transferTo` - Transfer tokens from signer - `dividendDistribution` - Distribute dividends - `newTokenizedAgent` / `agentRegister` - Register ERC-8004 agents - `agentSetURI`, `agentSetMetadata`, `agentSetWallet` - Maintain ERC-8004 agent profiles - `agentGiveFeedback`, `agentRevokeFeedback`, `agentAppendFeedbackResponse` - Manage reputation entries - `agentCreateToken`, `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. requestBody: required: true content: application/json: schema: description: >- Three mutually exclusive shapes, one per executionMode. Send exactly one of them. oneOf: - title: client-signed — you sign, Brickken broadcasts type: object required: - txId - signedTransactions properties: txId: oneOf: - type: string description: >- Transaction ID from the prepare-transactions response. example: >- 0x11769b5c2028a8ed0a3bdc7599e244aee68e2cae80261d8954e44c3b5cb621a4 - type: array items: type: string description: One ID per signed transaction, same order. description: >- Must match the format of signedTransactions: both strings, or both arrays of equal length. signedTransactions: oneOf: - type: string description: Legacy single-value form. example: 0x02f8b1018203e8843b9aca00850ba43b7400825208... - type: array items: type: string example: - 0x02f8b1018203e8843b9aca00850ba43b7400825208... description: >- Signed transaction hex string(s) starting with 0x. Never objects. - title: client-broadcast — you sign and broadcast, then confirm type: object required: - txId - txHash properties: txId: type: string description: Transaction ID from the prepare-transactions response. example: >- 0x11769b5c2028a8ed0a3bdc7599e244aee68e2cae80261d8954e44c3b5cb621a4 txHash: type: string description: >- Hash of the transaction you already broadcast yourself. Brickken reconciles it against the prepared record. example: >- 0x9f2c1f4b6e8a3d5c7b0e1a2d4f6c8b0a3e5d7c9f1b3a5c7e9d1f3b5a7c9e1d3f description: >- Requires exactly one txId and one txHash, and the prepare must have used executionMode: client-broadcast. Available for Dapp API methods as well as agentic ones. - title: brickken-relayed — Brickken signs and broadcasts type: object required: - txId - transactions properties: txId: type: string description: Transaction ID from the prepare-transactions response. example: >- 0x11769b5c2028a8ed0a3bdc7599e244aee68e2cae80261d8954e44c3b5cb621a4 transactions: type: array minItems: 1 maxItems: 1 items: $ref: '#/components/schemas/UnsignedTransaction' description: Exactly one prepared call, as returned by prepare. description: >- Requires x402 payment; API keys are not accepted on this path. responses: '200': description: Successful response content: application/json: schema: type: object properties: txHash: type: string description: Transaction hash of the submitted transaction example: 0x1234567890abcdef... status: type: string description: Transaction status example: pending '400': description: Bad Request - Invalid parameters content: application/json: schema: type: object properties: error: type: object properties: code: type: string example: INVALID_SIGNATURE message: type: string example: Transaction signature is invalid details: type: object properties: transactionIndex: type: integer example: 0 expectedSigner: type: string example: '0x742d35Cc6634C0532925a3b8D4C9db96c4b4d8b' actualSigner: type: string example: 0x... '402': description: >- x402 payment required. The response includes a PAYMENT-REQUIRED header with a base64-encoded x402 payment request. security: - apiKeyAuth: [] - x402Payment: [] components: schemas: UnsignedTransaction: type: object description: >- An unsigned transaction to sign. In client-signed and client-broadcast execution this is a fully populated EIP-1559 transaction; in brickken-relayed execution it is the bare call (to, data, value) that Brickken's relayer signs and broadcasts. BigNumber fields are serialised as { type, hex }. properties: to: type: string description: Target contract address. example: '0x23B04b6410D72Fa66A77a9e0146DF6634Ad4C462' data: type: string description: ABI-encoded calldata. example: >- 0xa9059cbb0000000000000000000000001111111111111111111111111111111111111111 from: type: string description: >- Signer address. Present in client-signed and client-broadcast execution. example: '0x742d35Cc6634C0532925a3b8D4C9db96c4b4d8b' value: type: object description: Native value sent with the call. properties: type: type: string example: BigNumber hex: type: string example: '0x00' nonce: type: integer description: Signer nonce at prepare time. example: 1 chainId: type: integer description: Operation chain, decimal. example: 11155111 type: type: integer description: Transaction type. 2 is EIP-1559. example: 2 gasLimit: type: object properties: type: type: string example: BigNumber hex: type: string example: '0x01e848' maxFeePerGas: type: object properties: type: type: string example: BigNumber hex: type: string example: '0x0ba43b7400' maxPriorityFeePerGas: type: object properties: type: type: string example: BigNumber hex: type: string example: '0x3b9aca00' required: - to - data example: from: '0x742d35Cc6634C0532925a3b8D4C9db96c4b4d8b' to: '0x23B04b6410D72Fa66A77a9e0146DF6634Ad4C462' value: type: BigNumber hex: '0x00' nonce: 1 chainId: 11155111 data: >- 0xa9059cbb0000000000000000000000001111111111111111111111111111111111111111 type: 2 gasLimit: type: BigNumber hex: '0x01e848' maxFeePerGas: type: BigNumber hex: '0x0ba43b7400' maxPriorityFeePerGas: type: BigNumber hex: '0x3b9aca00' securitySchemes: apiKeyAuth: type: apiKey in: header name: x-api-key x402Payment: type: apiKey in: header name: X-Payment description: >- Base64-encoded x402 payment payload. Supported for x402-eligible agentic methods on /x402/... facades, /prepare-transactions, and eligible /send-transactions retries. ````