Skip to main content
POST
Prepare a token mint
Prepares unsigned transactions for minting tokens to specified users. Use POST /prepare-transactions with method=mintToken. Minting increases the token’s current totalSupply and the recipient’s balance. It does not change the configured maximum supply.

Recipient Requirements

  • Every entry in userToMint needs a valid investorEmail and a positive whole-token amount.
  • investorEmail must be different from the token’s tokenizerEmail. Issuer and investor are separate email identities, even when they use the same wallet for sandbox testing. A collision returns investorEmail cannot be the tokenizer email (index N), where N is the position in userToMint.
  • Use the exact symbol from a successfully confirmed newTokenization. A symbol that does not resolve on the supplied chain returns No company found with this token symbol.
  • needWhitelist only determines whether the recipient is whitelisted with the mint. It does not change the identity requirement. It defaults to true unless explicitly set to false.
  • needKyc on a userToMint entry works the same way it does on whitelist, and false is accepted in Sandbox only.
Testing in Sandbox? Pass needKyc: false and skip identity verification entirely. The KYC flow is a Sumsub verification with document upload, not something you need to prove your integration works, and every test investor you create without it is one less manual step in your loop.Rehearse the real KYC flow once before you go live, since needKyc: false is rejected in production with needKyc=false is only available in the sandbox environment.
This method is an issuance-to-investors flow. It cannot mint to the tokenizer’s own identity, so there is no supported payload for minting into a company treasury.

Response shape

transactions is an array, as it is for every other prepare method. Iterate it rather than assuming a single entry: when a recipient still needs whitelisting, the response carries two transactions. When no recipient needs whitelisting:
When at least one recipient still needs whitelisting, the whitelist transaction comes first and txId carries the matching identifiers in the same order:
Sign and send all of them, in order, and wait for each to succeed before the next. The transactions carry sequential nonces, so broadcasting only the mint leaves it on a nonce that will never be used: it never mines, and the tokens never exist. A later burnToken or balance read then correctly reports no balance, which looks like an indexing lag but is not one.

Credits

Two independent counters can block a mint:
  • API-key mint credits, consumed once per mint operation at send time. Exhausting them returns Out of credits for minting.
  • License mint-recipient credits, counted per distinct recipient. Exhausting them returns Mint credit limit exceeded.
A recipient email that has never been invited also consumes an invitation credit; exhausting those returns Invitation credit limit exceeded. When more than one counter is exhausted the message lists them, for example Insufficient license credits: mint, invitation. None of these have a public reset endpoint. Contact support@brickken.com to review an account’s balances.
The first mint to a new recipient sends both a new-shareholder invitation and a token-received notification. Later mints to the same recipient send only the token-received notification.

Next step

Preparing does not touch the chain. The response gives you txId and an array of unsigned transactions — you still have to sign and submit them.
1

Sign every returned transaction

Sign each entry locally with the wallet that sends the transaction — signerAddress, or investorAddress for newInvest and claimTokens. It must be whitelisted by Brickken, and it needs native gas on the target chain.
2

Submit the signed payloads

POST them to /send-transactions as { txId, signedTransactions } and Brickken broadcasts for you.If you would rather broadcast yourself, prepare with executionMode: "client-broadcast" and confirm afterwards with { txId, txHash } instead.
3

Poll until it confirms

Call GET /get-transaction-status with the txId. A pending status means it is broadcast but not yet mined — do not resubmit.
Full walkthrough: Tokenize an asset and run an STO.

Authorizations

x-api-key
string
header
required

Body

application/json
method
enum<string>
default:mintToken
required

Required. Operation to prepare. Must be mintToken for this endpoint.

Available options:
mintToken
Example:

"mintToken"

chainId
string
required

Required. Blockchain network identifier. Hex format is recommended, for example Sepolia aa36a7.

Example:

"aa36a7"

signerAddress
string
required

Required. Tokenizer wallet that signs the mint transaction, and the whitelist transaction when recipients still need whitelisting.

Example:

"0x742d35Cc6634C0532925a3b844Bc454e4438f44e"

tokenSymbol
string
required

Required. Symbol of the token to mint. Its chainId must match the one in this request.

Example:

"EXMPL"

userToMint
object[]
required

Required. Users to mint tokens to.

Minimum array length: 1
Example:

Response

200 - application/json

Successful response

transactions
object[]
required

Unsigned transactions ready for signing, in the order they must be broadcast. Contains two entries when a recipient still needs whitelisting: the whitelist transaction first, then the mint.

txId
required

Identifier for this prepared transaction, required by /send-transactions. When transactions holds more than one entry this is an array of identifiers in the same order. This is NOT a blockchain transaction hash.

Example:

"0x46adea7bdf49c576a760102e0d6bc9ecd650b3998588cd3d7f576a7973426aad"

info
object

Metadata about the operation