Skip to main content
Every transaction on the Fireblocks platform is created with the same endpoint, Create a new transaction, and the operation field in the request body selects the transaction type. The default operation is TRANSFER. This page walks you through the shape of a request, setting up your client and sending your first transfer, and then covers how to run transaction creation securely and at scale. Once you have sent your first transaction, explore the other transaction types and the guides available for each of them.

Anatomy of a request

The fields below are shared by most transaction types. The API reference is the source of truth for full schemas, enums and limits. The valid source and destination peer types for each operation are listed in Sources and destinations, and the shape of the response is described in Transaction objects.

Choose an interface

You can create transactions with the Fireblocks SDKs, directly through the REST API or from the command line, and every guide in this section shows all three.

Set up your client

Every example in this section assumes you have already set up credentials for your chosen interface. Each option below reads your API key from the FIREBLOCKS_API_KEY environment variable and your private key from the file at FIREBLOCKS_SECRET_KEY_PATH, so no credentials appear in your code or shell history.
The SDK examples assume an initialized fireblocks client. Use BasePath.Sandbox to work against a sandbox workspace.

Your first transaction

The following example sends 0.001 ETH on the Sepolia testnet from one vault account to another, which is the simplest transaction you can create.
To send to a one-time address, an allowlisted wallet, an exchange account or several recipients at once, continue with Transfers.

After you submit

A successful request returns the new transaction’s ID and its initial status, and the transaction then moves through the approval, signing and blockchain confirmation stages on its own. Fireblocks recommends subscribing to webhooks to learn about status changes as they happen instead of polling the API, and you can read about the available statuses in Transaction statuses and about both approaches in Monitoring transaction status.

Secure and scale transaction creation

The sections below cover the practices that matter once you move from a first test transaction to a production integration.

Make requests idempotent

Network errors and timeouts can leave you unsure whether a request was processed, and retrying blindly risks sending the same transaction twice. To prevent that, include a unique externalTxId in the body of every transaction request, and Fireblocks rejects any later transaction request that reuses the same value. If a request fails with a network error, you can look the transaction up with Get a transaction by external ID to check whether the earlier attempt went through before you decide to resend it. See Transaction idempotency for details. Do not use the Idempotency-Key request header to create transactions, because it is meant for other endpoints.

Control what can be sent

The Transaction Authorization Policy decides which transactions are approved, which need extra approvals and which are blocked, and it applies to transactions created through the API in the same way as those created in the console. Sending to allowlisted destinations lets the policy restrict transfers to addresses you have already vetted, whereas one-time addresses let a transaction reach any address and are best governed by a stricter rule. If your workspace needs Travel Rule data on transfers, see the Travel Rule overview.

Automate signing

To approve and sign transactions without manual steps, use an API Co-signer. Start with the Co-signer architecture overview, run more than one Co-signer for resilience as described in multiple Co-signers for high availability, and use a callback handler to apply your own approval logic to each transaction.

Scale throughput

High transaction volumes on a single vault account can queue up behind each other, so Wallet Pools let you spread transactions across several vault accounts and use a WALLET_POOL as the source of a transfer. For sizing guidance and blockchain-specific recommendations, see Manage withdrawals at scale. On UTXO blockchains you can reduce the number of transactions by sending to multiple destinations in one request and by consolidating UTXOs during quiet periods. On EVM blockchains, the Gas Station keeps your vault accounts fueled and can use a Wallet Pool as its tank to avoid a single nonce stream becoming a bottleneck.

Handle fees and stuck transactions

Set the fee with the feeLevel field or with explicit fee parameters, and use fee estimation to see the current cost before you submit. If a transaction stays unconfirmed, you can boost or replace it, and Account Traffic Control and transaction timeouts help you detect and clear queues. Account Traffic Control sends a transaction.alert.stuck webhook when a transaction is stuck, and you can find more guidance in Manage withdrawals at scale.

Stay within rate limits

The API limits how many requests you can send in a given period, so design batch jobs and retries with that in mind. See Rate limiting for the current limits and how to handle throttled responses.

Explore transaction types

The table below lists the values of the operation field that most integrations use, grouped by what you want to do, and the API reference has the full list. Operations with their own guide include request examples for the SDK, the API and the CLI, and the rest link to the best existing reference.
If you issued your token with ERC-20F or another Fireblocks-deployed EVM token template, mint and burn it through the ERC-20F operational guide, which calls the token contract directly rather than using the MINT or BURN operation.
Transactions that you read back or receive in webhooks can also carry operations that you do not create with this endpoint, such as STAKE for staking activity. See Staking for how those transactions are created.