Advanced API for Crypto Trading

Bloom API for Developers: Build B2B Trading Tools and Solo Automation on Solana and EVM

If you want to drive crypto trades programmatically without building your own execution layer from scratch, the Bloom trading API is worth a close look. One API key covers swap execution, token deploys, and wallet management across Solana and EVM chains whether you're a team embedding execution into a product or a solo dev scripting a personal strategy without ever touching a terminal UI.

Here's how it's structured and how to get moving.

What the Bloom API Covers

Three core capabilities: swaps, token deploys, and wallet management.

Swaps are the main event. Buy or sell a token across one wallet or many, and attach automation directly in the request body take-profit, stop-loss, trailing, time-based, and dev-sell auto-orders are all supported. The execution engine handles the follow-through; you don't need to poll for status or wire up separate trigger logic.

Token deploys are Solana-only. You can launch on pump.fun, Bags, or Bonk with bundled buys and post-deploy distributions handled in a single call. If you're building launch tooling or running coordinated deploy strategies, this is the endpoint you want.

Wallet management is simpler a GET that returns the wallets tied to your account, including a `spot_active` flag. That flag tells you which wallets get used by default when you omit the `wallets` field in a swap request.

Endpoints and Base URLs

Three endpoints:

• `POST /api/v1/swap`
• `POST /api/v1/deploy`
• `GET /api/v1/wallets`

Solana swaps are served from two regional bases: `https://eu.solana.bloombot.app/api/v1/swap` and `https://us.solana.bloombot.app/api/v1/swap`. Same account, same wallets, same rate-limit budget — just pick whichever is geographically closer. Both regions also serve `/api/v1/deploy`.

EVM swaps go through a separate base: `https://evm.bloombot.app/api/v1/swap`. One key covers all EVM chains. The optional `chain` field accepts `eth`, `bsc`, `base`, `rbh`, or `arc`. Leave it out and the token resolves across chains automatically, handy when you're building something that handles tokens from multiple networks without asking users to specify a chain.

Supported chains: Solana, BNB Smart Chain, Base, Ethereum, RBH, HYPE, and ARC.

Authentication and Key Management

Authentication is a Bearer token in the `Authorization` header. Create the key in Bloom Manager, give it a name, and copy it immediately it's only shown once.

Keep it server-side. That's not optional. Never ship it in browser code or expose it in a client-facing application. For teams, your backend holds the key and your frontend calls your own API, which calls Bloom. For solo builders running scripts or bots, an environment variable is fine — just don't hardcode it in your source.

Rate Limits and What They Actually Mean

The rate limit is one shared allowance per user account, regardless of how many keys you've created: 60 requests per minute and 1,200 per hour.

Two things worth knowing before you build:

Rejected 429 responses don't count against your budget. If you hit the limit and get a rejection, that rejection itself doesn't consume an additional slot.

Also, `/ping` and `/wallets` never touch the rate limit at all. The docs recommend starting with both before your first swap, and you can use `/ping` as a keep-alive check without burning through your allowance.

Request Body Essentials

A swap request takes a token `address`, a `side` (Buy or Sell), and optionally a `wallets` array with per-wallet `address` and `amount` fields. Omit `wallets` and the swap runs across all spot-enabled wallets on the account using the top-level `amount`.

Other fields you can set per request: `slippage`, `priority_fee`, `processor_tip`, `anti_mev`, `auto_tip`, and `skip_if_bought`. That last one is worth understanding it checks the account's trade history and skips the buy if the token has already been purchased. Useful for multi-wallet strategies where you want to avoid accidentally duplicating a position.

Auto-orders go into an `auto_orders` array. Each entry specifies `target_type` (for example, `percentage`), `target_value`, `amount`, `slippage`, and `priority_fee`. You can also set liquidity and market-cap bounds per request to gate execution on conditions being met.

Understanding the Response

A successful call returns HTTP 200 with `{ success, data: { order_id, signatures, skipped } }`.

Here's the part that catches people off guard: HTTP 200 does not mean the swap is confirmed on-chain. The `signatures` field contains submitted transaction identifiers, not confirmation receipts. You still need to check chain confirmation separately using those signatures.

A skipped buy also returns 200 — with `skipped: true` and empty signatures. If you're building a system that logs outcomes, make sure your logic checks both `skipped` and `signatures` rather than treating any 200 as a completed trade.

Getting Started: A Short Checklist

Sourced directly from the recommended path in the API docs:

1. Create your API key in Bloom Manager — name it, copy it, store it server-side immediately.
2. Keep it server-side — environment variable in a script, secrets manager in a production service, never in browser code.
3. Hit `/ping` and `/wallets` — confirm connectivity and see which wallets are active before you build anything else. Neither call touches your rate limit.
4. Build your first swap — start simple: a single wallet, a known token address, a conservative slippage value. Verify the transaction on-chain using the returned signature before adding automation layers.

The B2B Use Case: Embedding Execution Into Your Product

Building a trading dashboard, a copy-trading platform, or an analytics tool that needs execution capabilities? Rather than building and maintaining your own swap infrastructure, you're routing through an execution engine that's already handling real volume.

The request and response shapes are consistent and predictable — that matters when you're building reliable integrations at scale. Multi-wallet support means you can serve multiple end users through a single integration pattern, and EVM chain auto-resolution cuts down on the chain-specific logic you'd otherwise need to handle yourself.

Fees are 1% per transaction, or 0.9% for referral and rewards program participants. No subscription fee on the API itself, so your cost scales with usage rather than a fixed monthly commitment.

The Solo Builder Use Case: Script Your Own Strategy

Sometimes you just want to run a specific strategy without paying for a full platform or learning multiple terminal interfaces. The API doesn't care, write exactly the logic you need and nothing more.

Multi-wallet execution, `skip_if_bought` guards, and auto-orders for take-profit and stop-loss are all accessible from a simple POST request. Run Solana strategies from the EU or US endpoint depending on your location, and EVM strategies from the single EVM endpoint with no per-chain key management to worry about.

Worth noting: the same engine that powers Bloom's retail product handles your API requests. You're not working with a stripped-down version of the execution layer.

FAQs

What chains does the Bloom API support? Solana, BNB Smart Chain, Base, Ethereum, RBH, HYPE, and ARC. EVM chains go through a single endpoint; Solana has separate EU and US regional endpoints.

Does one API key cover all chains? For EVM, yes, one key, one endpoint, all chains. Solana uses the same account and key but routes through the Solana-specific endpoints.

What happens if I hit the rate limit? You get a 429. That rejection doesn't count against your budget, so you're not penalized twice. Also worth knowing: `/ping` and `/wallets` never consume any allowance regardless of how often you call them.

Does HTTP 200 mean my swap went through? No, and this one trips people up. A 200 means the request was accepted and transactions were submitted, not that they confirmed on-chain. Check confirmation separately using the signatures in the response. A skipped buy also returns 200, with `skipped: true` and empty signatures, so don't treat every 200 as a completed trade.

Can I attach take-profit and stop-loss to a swap via the API? Yes. The `auto_orders` array accepts take-profit, stop-loss, trailing, time-based, and dev-sell orders, each with its own target type, target value, amount, and fee settings.

Is token deployment available on EVM chains? No, `/deploy` is Solana-only. It supports launches on pump.fun, Bags, and Bonk with bundled buys and post-deploy distributions.

Where do I create an API key? In Bloom Manager at bloombot.app. Name the key, copy it when shown, store it immediately — it's only displayed once.

Start Building

The docs recommend the same path every time: create your key in Bloom Manager, confirm connectivity with `/ping`, inspect your wallets, then build your first swap. The full API reference is at bloombot.app. If you want the browser-side experience running alongside your scripts, the Chrome extension installs in one step from the same account.