Tokenize an asset and run an STO

Every step below is the same three moves: prepare an unsigned transaction, sign it with your whitelisted wallet, send it. The examples target Sepolia (aa36a7) on sandbox, so nothing here moves real value.

Before you start

Get an API key

Request one. Every call below needs x-api-key.

Get your signer whitelisted

Brickken must whitelist the wallet you pass as signerAddress before any prepare call accepts it. Ask for it in the same request as the key.

Fund that wallet with native gas

You broadcast the transactions, so the signer pays the gas — Sepolia ETH here.

The wallet that performs the first newTokenization becomes the tokenizer for that token. Only the tokenizer can mint it, whitelist its investors, or distribute its dividends. Transfers and burns can come from any wallet. Your API key is also scoped to the symbols it tokenized — anything else returns Unauthorized token symbol.

The sign-and-send loop

You will repeat this after every prepare, so it is worth writing once. Prepare returns { txId, transactions }:

curl --request POST 'https://api.sandbox.brickken.com/send-transactions' \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: YOUR_BRICKKEN_API_KEY' \
  --data '{
    "txId": "0xPreparedTransactionId",
    "signedTransactions": ["0xSignedRawTransaction"]
  }'

Signing, with ethers:

import { Wallet } from "ethers";

const wallet = new Wallet(process.env.PRIVATE_KEY!);
const signedTransactions = await Promise.all(
  prepared.transactions.map((tx) => wallet.signTransaction(tx))
);

Then poll until it confirms:

curl 'https://api.sandbox.brickken.com/get-transaction-status?txId=0xPreparedTransactionId' \
  --header 'x-api-key: YOUR_BRICKKEN_API_KEY'

pending means broadcast but not yet mined. Do not resubmit — you would pay gas twice.

Treat every successful transaction as a dependency boundary. Before preparing newSto, mintToken, or whitelist, poll the preceding newTokenization until it succeeds. A send response only means the transaction was broadcast; a reverted receipt does not create the token record used by later methods.

Already run your own broadcasting? Add "executionMode": "client-broadcast" to any prepare below, submit the signed transaction to the chain yourself, then confirm with { txId, txHash } instead of { txId, signedTransactions }. Brickken reconciles your hash so the transaction still appears in get-transaction-status and in the dApp. See Send Transactions.

1. Create the tokenized asset

curl --request POST 'https://api.sandbox.brickken.com/prepare-transactions' \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: YOUR_BRICKKEN_API_KEY' \
  --data '{
    "method": "newTokenization",
    "signerAddress": "0xYourWhitelistedWallet",
    "chainId": "aa36a7",
    "tokenizerEmail": "issuer@example.com",
    "name": "Example Asset",
    "tokenSymbol": "EXMPL",
    "tokenType": "EQUITY",
    "supplyCap": "1000000",
    "url": "https://example.com/token-docs"
  }'

The field is name, not tokenName. tokenType accepts EQUITY, DEBT, BILL_FACTORING, ICO, STABLECOIN, REVENUE_SHARE, RWA_TOKEN, or PROFIT_SHARING, and defaults to EQUITY. supplyCap defaults to 0, which means uncapped — set it deliberately. Sign and send, then confirm the token exists. The endpoint lists all symbols available to your API key; use the exact confirmed symbol in every later request.

curl 'https://api.sandbox.brickken.com/get-token-info' \
  --header 'x-api-key: YOUR_BRICKKEN_API_KEY'

Every field, with the request and response schema, is on the newTokenization reference.

2. Whitelist your investors

A security token only moves between whitelisted wallets. Whitelist before you mint or accept investment.

curl --request POST 'https://api.sandbox.brickken.com/prepare-transactions' \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: YOUR_BRICKKEN_API_KEY' \
  --data '{
    "method": "whitelist",
    "signerAddress": "0xYourWhitelistedWallet",
    "chainId": "aa36a7",
    "tokenSymbol": "EXMPL",
    "userToWhitelist": [
      {
        "investorAddress": "0x1111111111111111111111111111111111111111",
        "investorEmail": "investor@example.com",
        "whitelistStatus": true
      }
    ]
  }'

whitelistStatus: false removes an investor. Verify with GET /get-whitelist-status.

3. Mint tokens

curl --request POST 'https://api.sandbox.brickken.com/prepare-transactions' \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: YOUR_BRICKKEN_API_KEY' \
  --data '{
    "method": "mintToken",
    "signerAddress": "0xYourWhitelistedWallet",
    "chainId": "aa36a7",
    "tokenSymbol": "EXMPL",
    "userToMint": [
      {
        "investorEmail": "investor@example.com",
        "investorAddress": "0x1111111111111111111111111111111111111111",
        "amount": "100",
        "needWhitelist": true
      }
    ]
  }'

needWhitelist: true whitelists the recipient as part of the same mint, which collapses step 2 into step 3 when you are onboarding a new investor.

investorEmail must identify an investor distinct from the asset’s tokenizerEmail. Do not use the issuer/tokenizer email as the mint recipient: it can conflict with the issuer account in the investor records. The recipient may use the same wallet address as the tokenizer for sandbox testing; only the email identities must differ. needWhitelist controls the whitelist sub-step and does not change this identity rule.

4. Launch the offering

curl --request POST 'https://api.sandbox.brickken.com/prepare-transactions' \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: YOUR_BRICKKEN_API_KEY' \
  --data '{
    "method": "newSto",
    "signerAddress": "0xYourWhitelistedWallet",
    "chainId": "aa36a7",
    "tokenizerEmail": "issuer@example.com",
    "tokenSymbol": "EXMPL",
    "tokenAmount": "1000",
    "offeringName": "Series A",
    "startDate": "2026-09-01T00:00:00.000Z",
    "endDate": "2026-12-31T23:59:59.000Z",
    "acceptedCoin": "USDT",
    "minRaiseUSD": "10000",
    "maxRaiseUSD": "100000",
    "minInvestment": "100",
    "maxInvestment": "10000"
  }'

Every one of those fields is required. Dates are ISO 8601. acceptedCoin is a payment token symbol — USDT, USDC, or BKN.

startDate is checked against the block timestamp when the STO transaction is mined, not when you prepare it. Set it at least 10 minutes after the time you expect to call send-transactions, then sign and broadcast promptly. A date that has elapsed while signing, sending, or waiting for inclusion causes the transaction to revert even when prepare and send succeeded.

Once it is live, list your offerings and keep the uuid:

curl 'https://api.sandbox.brickken.com/get-stos?chainId=aa36a7&tokenSymbol=EXMPL' \
  --header 'x-api-key: YOUR_BRICKKEN_API_KEY'

5. Take an investment

Note there is no signerAddress in the required set — the investor signs this one, not the tokenizer.

curl --request POST 'https://api.sandbox.brickken.com/prepare-transactions' \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: YOUR_BRICKKEN_API_KEY' \
  --data '{
    "method": "newInvest",
    "chainId": "aa36a7",
    "tokenSymbol": "EXMPL",
    "investorEmail": "investor@example.com",
    "investorAddress": "0x1111111111111111111111111111111111111111",
    "investmentAmount": "1000",
    "paymentTokenSymbol": "USDT"
  }'

The investor needs the payment token in their wallet, and the prepare response may contain two transactions — an ERC-20 approve followed by the investment. Sign and send both, in order. Track progress with GET /get-investments-by-sto-id and GET /get-sto-balance.

6. Let investors claim their tokens

curl --request POST 'https://api.sandbox.brickken.com/prepare-transactions' \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: YOUR_BRICKKEN_API_KEY' \
  --data '{
    "method": "claimTokens",
    "chainId": "aa36a7",
    "tokenSymbol": "EXMPL",
    "investorEmail": "investor@example.com",
    "investorAddress": "0x1111111111111111111111111111111111111111"
  }'

The investor signs this too.

7. Close the offering

curl --request POST 'https://api.sandbox.brickken.com/prepare-transactions' \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: YOUR_BRICKKEN_API_KEY' \
  --data '{
    "method": "closeOffer",
    "signerAddress": "0xYourWhitelistedWallet",
    "chainId": "aa36a7",
    "tokenSymbol": "EXMPL",
    "tokenizerEmail": "issuer@example.com"
  }'

8. Distribute dividends

curl --request POST 'https://api.sandbox.brickken.com/prepare-transactions' \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: YOUR_BRICKKEN_API_KEY' \
  --data '{
    "method": "dividendDistribution",
    "signerAddress": "0xYourWhitelistedWallet",
    "chainId": "aa36a7",
    "tokenSymbol": "EXMPL",
    "amount": "1000"
  }'

Only the tokenizer can do this. Read the result with GET /get-dividend-distribution.

When something fails

Response	What it means
`401` / `400 API key is missing`	No `x-api-key`, or this endpoint needs one and did not get it
`Unauthorized token symbol`	Your key did not tokenize that symbol
`Out of credits for <method>`	Your plan’s balance for that specific method is exhausted
`429` + `Retry-After: 60`	Rate limited on `prepare-transactions`
Prepare rejects your `signerAddress`	The wallet is not whitelisted yet
`No company found with this token symbol`	The symbol is not a successfully confirmed asset on that chain; inspect `GET /get-token-info` and use the exact symbol it lists
Mint returns a uniqueness conflict	The recipient email is already the asset’s tokenizer email; use a distinct `investorEmail`
`newSto` reverts after send	`startDate` became past or too close by the mined block; retry with at least a 10-minute send-time buffer
Send reverts on-chain	Usually an unwhitelisted recipient, an unapproved allowance, or no gas

Each write method has its own credit balance, so exhausting mintCredits does not block newSto. See Authentication for plans, scoping, and the full error reference.

Doing this without writing HTTP

MCP server

The same lifecycle as agent tools — create_tokenization, create_sto, mint_tokens — driven by an AI agent with just your API key.

Postman collection

Every request above, ready to run.

Overview

Guides

Prepare Transactions

Send Transactions

Read Endpoints

Token Documents

Before you start

The sign-and-send loop

1. Create the tokenized asset

2. Whitelist your investors

3. Mint tokens

4. Launch the offering

5. Take an investment

6. Let investors claim their tokens

7. Close the offering

8. Distribute dividends

When something fails

Doing this without writing HTTP

MCP server

Postman collection

​Before you start

​The sign-and-send loop

​1. Create the tokenized asset

​2. Whitelist your investors

​3. Mint tokens

​4. Launch the offering

​5. Take an investment

​6. Let investors claim their tokens

​7. Close the offering

​8. Distribute dividends

​When something fails

​Doing this without writing HTTP

MCP server

Postman collection

Before you start

The sign-and-send loop

1. Create the tokenized asset

2. Whitelist your investors

3. Mint tokens

4. Launch the offering

5. Take an investment

6. Let investors claim their tokens

7. Close the offering

8. Distribute dividends

When something fails

Doing this without writing HTTP