# Binance API

- Tool: Bubble
- Difficulty: Intermediate
- Time required: 2–4 hours
- Last updated: July 2026

## TL;DR

Connect Bubble to Binance's API in two tiers: public market data endpoints (spot prices, OHLCV charts, orderbook) work via API Connector with just an X-MBX-APIKEY Private header — no CORS issues since Bubble proxies server-side. Private account endpoints (balances, trade history, order placement) additionally require HMAC-SHA256 signature computation that Bubble cannot perform natively, so those require an external signing helper called from a Backend Workflow.

## Binance + Bubble: two integration tiers with very different complexity levels

Binance's API splits cleanly into two tiers, and understanding this split before you build saves hours of confusion.

**Tier 1 — Public market data (straightforward).** Endpoints like GET /api/v3/ticker/price (spot price), GET /api/v3/klines (OHLCV candlestick data), and GET /api/v3/depth (orderbook) are accessible with just the X-MBX-APIKEY header. No user authentication, no session tokens, no OAuth flow. Add the API key as a Private header in Bubble's API Connector and you can build a live crypto price widget in under an hour. Because Bubble's API Connector runs server-side, CORS — which blocks every browser from calling Binance directly — is completely avoided.

**Tier 2 — Private account endpoints (significantly more complex).** Endpoints for account balances (GET /api/v3/account), trade history (GET /api/v3/myTrades), and order placement (POST /api/v3/order) require a per-request HMAC-SHA256 signature. This signature is a cryptographic hash of the query string using the API secret as the key. The signature changes on every request because it includes a timestamp. Bubble's API Connector cannot compute HMAC-SHA256 natively — there is no built-in cryptographic function. Private endpoints need an external signing helper (a small Cloudflare Worker or similar serverless function) that Bubble's Backend Workflow calls to generate the signature before the actual Binance request.

This tutorial covers Tier 1 fully (price tickers and market data) and explains the Tier 2 architecture clearly so you can decide what to build.

**Binance's weight system.** Each API endpoint has a 'weight' cost. You get 1,200 weight units per minute. A single symbol ticker costs 1 weight; fetching all symbols costs 2 weight. Exceeding 1,200 weight/min triggers a 429 response and a temporary IP ban. For Repeating Groups refreshing price data, poll no faster than every 30 seconds.

## Before you start

- A Binance account (free) with API access enabled
- A Binance API key and secret generated at binance.com → Profile → API Management (or Binance testnet keys from testnet.binance.vision for safe testing)
- API Connector plugin installed in your Bubble app (Plugins → Add plugins → search 'API Connector' → Install)
- For private endpoints only: a Bubble account on Starter plan or higher (Backend Workflows required) and an external signing service for HMAC-SHA256

## Step-by-step guide

### 1. Step 1: Generate your Binance API key with appropriate permissions

Log into your Binance account at binance.com. Go to your profile (top right) → **API Management**. Click **Create API** and give it a label like 'Bubble Integration'.

Bindings you will see:
- **Enable Reading**: required for all read operations (prices, balances, trade history). Check this.
- **Enable Spot & Margin Trading**: required only if you plan to place orders from Bubble. Leave unchecked for a read-only price/portfolio display app.
- **Enable Withdrawals**: leave unchecked — never enable this for a Bubble integration unless your app's specific purpose is withdrawal management.
- **Restrict access to trusted IPs**: highly recommended. Add the IP addresses that Bubble uses to make requests (you can find these in Bubble's documentation or use Cloudflare proxying). For development and testing, you may leave this open temporarily, but set it before going live.

Once created, Binance shows you the API Key and Secret Key once. Copy both immediately — the Secret Key is never shown again. Store both securely.

For testing order placement without using real funds: go to testnet.binance.vision and create separate testnet API keys there. The testnet uses the same API structure as production but operates with virtual funds. Testnet keys only work against https://testnet.binance.vision — they do not work against the production URL.

```
// Binance API key permissions for different use cases:
// Price ticker / market data only: Enable Reading = ON
// Portfolio display (account balances): Enable Reading = ON
// Order placement: Enable Reading = ON + Enable Spot Trading = ON
// NEVER enable Withdrawals for a Bubble integration

// IP Whitelist recommendation:
// Before going live, add Bubble's server IP range
// For testnet only: https://testnet.binance.vision
// API keys: generate separately at testnet.binance.vision
```

**Expected result:** A Binance API key and secret are ready. For price ticker testing, a read-only key is sufficient. For testnet order testing, separate testnet keys from testnet.binance.vision are available.

### 2. Step 2: Configure API Connector with X-MBX-APIKEY as Private header

In your Bubble editor, click the **Plugins** tab in the left sidebar. Click **API Connector** (if not installed: Add plugins → search 'API Connector' → Install). Click **Add another API** to create a new API group. Name it 'Binance'.

Set the base URL to `https://api.binance.com` (or `https://testnet.binance.vision` for testnet development).

In the **Shared headers** section, click the + to add a header:
- Header name: `X-MBX-APIKEY`
- Value: your Binance API key
- Check the **Private** checkbox

The Private checkbox is essential. Without it, the API key appears in your app's browser network requests and anyone with DevTools access can see it. With Private, Bubble substitutes the key on the server before the request leaves Bubble's infrastructure.

Now add the Initialize Call to verify connectivity. Click **Add a call**, name it 'Ping Binance'. Set method to GET, path to `/api/v3/ping`. This endpoint returns an empty JSON object `{}` with a 200 status — it is specifically designed as a connectivity check with zero weight cost. Click **Initialize call**. You should see the 200 response immediately.

Add a second call named 'Get BTC Price'. Set method to GET, path to `/api/v3/ticker/price`. Add a query parameter: `symbol` with a test value of `BTCUSDT`. Click **Initialize call** with the test value. The response is: `{"symbol": "BTCUSDT", "price": "65432.12000000"}`. Bubble auto-detects the `symbol` and `price` fields.

```
// API Connector — Binance group configuration
{
  "api_name": "Binance",
  "base_url": "https://api.binance.com",
  "shared_headers": [
    {
      "name": "X-MBX-APIKEY",
      "value": "<your_binance_api_key>",
      "private": true
    }
  ]
}

// Initialize Call 1: Ping
{
  "method": "GET",
  "path": "/api/v3/ping",
  "response": {}  // Empty object = success
}

// Initialize Call 2: BTC Price
{
  "method": "GET",
  "path": "/api/v3/ticker/price",
  "params": { "symbol": "BTCUSDT" },
  "response": {
    "symbol": "BTCUSDT",
    "price": "65432.12000000"
  }
}
```

**Expected result:** The Binance API Connector group is configured with a Private X-MBX-APIKEY header. The 'Ping Binance' Initialize Call returns {}. The 'Get BTC Price' Initialize Call returns symbol and price fields. Both calls are initialized and saved.

### 3. Step 3: Add market data calls for OHLCV charts and orderbook

With the base configuration working, add additional market data calls.

**Candlestick/OHLCV data** (GET /api/v3/klines): This returns arrays of price data for charting. Add a call named 'Get Klines'. Set method to GET, path to `/api/v3/klines`. Add parameters: `symbol` (BTCUSDT), `interval` (1h), `limit` (100 — number of candles to return). Initialize with these test values.

The klines response is an array of arrays — each inner array contains [openTime, open, high, low, close, volume, closeTime, quoteVolume, numberOfTrades, takerBuyBaseVolume, takerBuyQuoteVolume, ignore]. Bubble will detect this as a list of lists. To bind individual fields, use list index operators in Bubble's expression builder.

**24-hour ticker statistics** (GET /api/v3/ticker/24hr): Returns 24-hour price change, high, low, volume, and last price for a symbol. Weight cost is 1 for a specific symbol. Add a call named 'Get 24hr Stats' with parameter `symbol`. The response includes `priceChangePercent`, `highPrice`, `lowPrice`, `volume`, `lastPrice` — useful for a market summary card.

**Order book** (GET /api/v3/depth): Returns bid and ask levels. Add a call named 'Get Orderbook' with parameters `symbol` and `limit` (5 for a lightweight display, up to 5000 for deep analysis). Weight cost varies by limit: 5–10 records costs 1 weight, up to 100 costs 2, up to 500 costs 5.

For a multiple-cryptocurrency dashboard (BTC, ETH, BNB), call /api/v3/ticker/price without the symbol parameter — the response is a JSON array of all trading pairs. Weight cost is 2 but returns all pairs at once, which is more efficient than one call per symbol if you need 5+ prices.

```
// GET /api/v3/klines — candlestick data
{
  "method": "GET",
  "path": "/api/v3/klines",
  "params": {
    "symbol": "BTCUSDT",
    "interval": "1h",     // Options: 1m, 3m, 5m, 15m, 30m, 1h, 4h, 1d, 1w, 1M
    "limit": "100"        // Max 1000, default 500
  }
}
// Response: array of arrays
// Each: [openTime, open, high, low, close, volume, closeTime, ...]

// GET /api/v3/ticker/24hr — 24h stats
{
  "method": "GET",
  "path": "/api/v3/ticker/24hr",
  "params": { "symbol": "BTCUSDT" },
  "response_fields": ["priceChangePercent", "highPrice", "lowPrice", "volume", "lastPrice"]
}

// GET /api/v3/depth — orderbook
{
  "method": "GET",
  "path": "/api/v3/depth",
  "params": { "symbol": "BTCUSDT", "limit": "5" },  // 1 weight
  "response_fields": ["bids", "asks"]  // Each: [[price, quantity], ...]
}

// Weight costs:
// /api/v3/ping → 1 weight
// /api/v3/ticker/price (one symbol) → 1 weight
// /api/v3/ticker/price (all symbols) → 2 weight
// /api/v3/ticker/24hr → 1 weight per symbol
// /api/v3/klines → 1 weight
```

**Expected result:** API calls for klines, 24hr ticker stats, and orderbook are configured and initialized. Each call shows auto-detected response fields in Bubble. You can now bind these to chart elements and text elements on your page.

### 4. Step 4: Build the price ticker UI with auto-refresh

Create the price display UI in your Bubble page editor.

For a single-coin price ticker:
1. Drag a **Text** element onto your page
2. Set the content to 'Get data from an external API → Binance - Get BTC Price → price'
3. Format as currency or a number with 2 decimal places

For auto-refresh, add a page workflow:
1. Click the page to open its workflow
2. Add an event: 'When → Every X seconds' → set to 30 seconds (minimum recommended; every 15 seconds doubles your WU cost for minimal benefit)
3. Add action: 'Refresh data source' → select the Get BTC Price API call data source

For a multi-cryptocurrency Repeating Group:
1. Create a Repeating Group
2. Set Type of content to 'Binance — Get All Prices' (the unfiltered /ticker/price call)
3. Add text elements inside for 'symbol' and 'price'
4. Add a search/filter above the Repeating Group to let users search by symbol name

For error handling in the UI:
Binance error responses use a 'code' field with a negative integer and a 'msg' field. Add a conditional to your workflow: if the API response contains 'code', show a text element with the error message. Common codes:
- -1100: Illegal characters in parameter
- -1121: Invalid symbol
- 429: Rate limit exceeded (also triggers an HTTP 429 status)

```
// Page workflow for 30-second price refresh
// Event: Every 30 seconds
// Action: Refresh data source → Binance - Get BTC Price

// Binance error response format:
{
  "code": -1121,
  "msg": "Invalid symbol."
}

// Conditional to display errors in Bubble:
// When: Binance - Get BTC Price's code is not empty
// Show element: Error Text
// Error Text content: Binance - Get BTC Price's msg

// Weight calculation for 30-second polling:
// 1 call per 30 seconds = 2 calls/minute
// At 1 weight each = 2 weight/minute
// Budget: 1200 weight/minute
// Safe margin: extremely wide — 1 ticker widget has minimal impact
```

**Expected result:** A price ticker text element displays the live BTC/USDT price. A page workflow refreshes the price every 30 seconds. Error handling shows a user-friendly message if the API returns an error code.

### 5. Step 5: Understand the HMAC-SHA256 requirement for private endpoints

If you need account balances, trade history, or order placement — private Binance endpoints — you need to understand why these cannot be configured the same way as market data calls.

Private Binance endpoints require three additional request components:
1. **timestamp**: the current Unix timestamp in milliseconds, appended as a query parameter
2. **recvWindow**: optional but recommended — the time window (in milliseconds) during which the request is valid; default 5000ms, max 60000ms
3. **signature**: an HMAC-SHA256 hash of the complete query string (including timestamp) using your API secret as the key

The signature formula: `HMAC-SHA256(query_string, api_secret)`. The query string includes ALL parameters: `symbol=BTCUSDT&side=BUY&type=MARKET&quantity=0.001&timestamp=1703548800000`. The resulting hex signature is appended as `&signature=<hex_hash>`.

Why Bubble cannot compute this natively: Bubble's API Connector has no built-in cryptographic functions. There is no Bubble action or expression that computes HMAC-SHA256. This is the real limitation for private endpoints — not CORS, not authentication headers.

The recommended architecture: build a small Cloudflare Worker (or similar lightweight serverless function) that accepts `{queryString, apiSecret}` and returns the HMAC-SHA256 hex signature. Your Bubble Backend Workflow calls this signing service first, gets the signature, then calls the actual Binance endpoint with all parameters including the signature. The API secret never leaves your signing service — Bubble only receives and uses the computed signature string.

```
// Private endpoint call flow:
// 1. Build query string in Backend Workflow:
//    timestamp=<current_unix_ms>&symbol=BTCUSDT
// 2. Call signing service (Cloudflare Worker):
//    POST https://your-signing-worker.your-domain.workers.dev/sign
//    Body: { "queryString": "timestamp=1703548800000&symbol=BTCUSDT", "secret": "<api_secret>" }
// 3. Signing service returns: { "signature": "6a6574da..." }
// 4. Call Binance with full signed URL:
//    GET https://api.binance.com/api/v3/account
//       ?timestamp=1703548800000&recvWindow=5000&signature=6a6574da...

// Example signing worker (Cloudflare Workers / JavaScript):
export default {
  async fetch(request) {
    const { queryString, secret } = await request.json();
    const encoder = new TextEncoder();
    const keyData = encoder.encode(secret);
    const key = await crypto.subtle.importKey('raw', keyData, { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']);
    const msgData = encoder.encode(queryString);
    const signature = await crypto.subtle.sign('HMAC', key, msgData);
    const hex = Array.from(new Uint8Array(signature)).map(b => b.toString(16).padStart(2, '0')).join('');
    return Response.json({ signature: hex });
  }
};

// After signing, call Binance private endpoint:
// GET /api/v3/account?timestamp=1703548800000&signature=<hex_signature>
```

**Expected result:** You understand the two-tier Binance API model. For private endpoints, you have a plan: either build the HMAC signing infrastructure (Cloudflare Worker + Bubble Backend Workflow) or use Plaid as the official alternative for portfolio data.

### 6. Step 6: Test safely with Binance testnet before going to production

Before connecting your Bubble app to real Binance funds, validate the full integration using Binance's testnet environment.

To get testnet credentials:
1. Go to testnet.binance.vision
2. Click 'Login with GitHub' to authenticate
3. Generate testnet API keys (separate from your production keys)
4. The testnet provides virtual USDT and BTC balances for testing order placement

In your Bubble API Connector, for testnet configuration:
- Change the base URL from `https://api.binance.com` to `https://testnet.binance.vision`
- Swap the X-MBX-APIKEY value to your testnet API key
- All endpoint paths remain the same

Testnet endpoints available:
- GET /api/v3/ticker/price — testnet prices (may differ from production market prices, as testnet is a simulated market)
- GET /api/v3/account — testnet account with virtual funds
- POST /api/v3/order — place test orders with virtual funds (safe, no real money involved)

For price tickers, testnet prices are simulated and may not match real market prices. For testing the UI layout and API call configuration, this is fine. For testing actual order execution logic, testnet is ideal — it mirrors production behavior exactly but with no financial risk.

When switching from testnet to production: update the base URL back to `https://api.binance.com`, update the API key to your production key, re-initialize any calls that have changed parameters, and add IP whitelisting to your production API key in the Binance console.

RapidDev's team builds Bubble apps with complex financial API integrations — if you want a free scoping call to review your architecture before going live, visit rapidevelopers.com/contact.

```
// Testnet vs Production comparison:
{
  "testnet": {
    "base_url": "https://testnet.binance.vision",
    "api_key": "<testnet_key_from_testnet.binance.vision>",
    "funds": "Virtual (no real money)",
    "prices": "Simulated (may differ from real market)"
  },
  "production": {
    "base_url": "https://api.binance.com",
    "api_key": "<production_key_from_binance.com>",
    "funds": "Real Binance account",
    "prices": "Live market data"
  }
}

// Testnet account balance check:
// GET https://testnet.binance.vision/api/v3/account
// (with testnet key and HMAC signature)
// Returns virtual balance: { "balances": [{ "asset": "USDT", "free": "10000" }] }

// Switching checklist:
// 1. Update base_url → https://api.binance.com
// 2. Update X-MBX-APIKEY → production key
// 3. Re-initialize API Connector calls if needed
// 4. Enable IP whitelist on production key
```

**Expected result:** Your Bubble app is fully tested against Binance testnet. Price tickers display simulated data. Order placement (if built) works with virtual funds. All error handling is verified. You have a clear checklist for switching to production.

## Best practices

- Always use the API Connector (server-side) for Binance calls — never try to call Binance from client-side JavaScript in Bubble, as CORS restrictions block all browser-origin requests to Binance.
- Mark X-MBX-APIKEY as Private in the API Connector shared headers — without the Private checkbox, your API key appears in browser network requests and can be stolen by anyone inspecting your app's traffic.
- Poll market data no faster than every 30 seconds in Repeating Groups — Binance's 1,200 weight unit per minute limit and temporary IP bans for exceeding it make aggressive polling counterproductive.
- Create a read-only API key for price display and portfolio viewing apps — never enable Spot Trading or Withdrawal permissions unless your Bubble app specifically needs order placement; a leaked read-only key can see balances but cannot move funds.
- Use IP whitelisting on your production Binance API key — add Bubble's server IP addresses to the key's allowed IPs in your Binance API Management settings; a key restricted to known IPs cannot be used from an attacker's IP even if stolen.
- For private endpoint (account balance, trade history) needs, consider using Plaid's Investment Holdings API as the official alternative — Plaid supports Binance account connections, handles authentication properly, and doesn't require building HMAC signing infrastructure.
- Use Binance's testnet (testnet.binance.vision) for all development testing — same API surface as production, virtual funds for order testing, completely separate key set so no risk to real funds during development.
- Cache prices in a Bubble database table for high-traffic apps instead of making one API call per user session — a Backend Workflow updates the cached price every 30 seconds, and all user-facing pages read from the database rather than hitting Binance directly.

## Use cases

### Live crypto price ticker widget

Display real-time spot prices for BTC, ETH, and other cryptocurrencies in a Bubble app. Use GET /api/v3/ticker/price?symbol=BTCUSDT and auto-refresh every 30 seconds via Bubble's 'every X seconds' element workflow. Costs 1 weight unit per call — very low impact.

### Candlestick chart for market analysis

Pull OHLCV (open, high, low, close, volume) data with GET /api/v3/klines to display a price history chart. Bind the response array to a Bubble chart element. Choose intervals like 1h, 4h, 1d — the `interval` parameter accepts '1m', '5m', '1h', '4h', '1d', '1w' and more.

### Portfolio tracker with private account data

Show a user's Binance account balances and holdings using GET /api/v3/account. This endpoint requires HMAC-SHA256 signing via a Backend Workflow and an external signing helper, plus timestamp parameter within 5 seconds of Binance server time.

## Troubleshooting

### CORS error when trying to call Binance API from a Bubble app

Cause: This happens when someone tries to call the Binance API from Bubble's client-side (a 'Run JavaScript' action or a direct browser call) instead of using the API Connector. Binance does not allow browser-origin requests due to CORS policy.

Solution: Use Bubble's API Connector exclusively for Binance calls. The API Connector runs server-side (from Bubble's servers), which completely bypasses CORS restrictions. Do not use 'Run JavaScript' or any client-side approach to call Binance endpoints. All Binance calls should flow through API Connector calls triggered from Bubble workflows.

### Binance returns error code -1021 'Timestamp for this request is outside of the recvWindow'

Cause: For private endpoints, the timestamp parameter in the request must be within 5000ms (±) of Binance's server time. If there is clock drift between when the timestamp was generated and when the request arrives at Binance, it gets rejected.

Solution: Add a call to GET /api/v3/time in your Backend Workflow to retrieve Binance's server time before each signed request. Use the returned serverTime value as your timestamp parameter instead of generating it from Bubble's current date/time. Alternatively, increase the recvWindow parameter up to 60000ms (60 seconds) as a tolerance buffer, though Binance recommends staying within 5000ms.

```
// GET /api/v3/time — fetch Binance server time
{
  "method": "GET",
  "path": "/api/v3/time",
  "response": { "serverTime": 1703548800000 }
}
// Use serverTime as the timestamp parameter in signed requests
```

### Binance returns 429 rate limit error and subsequent calls fail

Cause: The 1,200 weight unit per minute limit has been exceeded. This can happen with rapidly refreshing price displays, batch operations, or multiple users all polling simultaneously through the same Bubble app IP.

Solution: Reduce polling frequency to a minimum of 30 seconds per refresh. Use the /api/v3/ticker/price call without a symbol parameter (returns all pairs for 2 weight) instead of one call per cryptocurrency (1 weight each). For high-traffic apps, cache prices in a Bubble database table using a scheduled Backend Workflow, and have all users read from the database. After a 429, Bubble will see HTTP 429 — add an error handler that waits 60 seconds before retrying.

### There was an issue setting up your call — Initialize Call fails for market data endpoints

Cause: The Initialize Call needs a real successful API response. If the base URL is wrong, the API key is invalid or missing, or the symbol parameter is incorrect, Bubble receives a non-200 response and shows the generic initialization error.

Solution: First verify the endpoint URL in a browser or Postman: https://api.binance.com/api/v3/ticker/price?symbol=BTCUSDT should return a JSON price response immediately. Then in Bubble, ensure the base URL is set to https://api.binance.com (not with a trailing slash) and the X-MBX-APIKEY header is filled in with your actual API key. For the Initialize Call test parameters, enter BTCUSDT as the symbol value and click Initialize call. The response should auto-detect 'symbol' and 'price' fields.

### Binance returns error code -1022 'Signature for this request is not valid'

Cause: The HMAC-SHA256 signature is incorrect. This occurs when the query string used to generate the signature does not exactly match the query string sent in the request, or when the API secret used for signing is wrong.

Solution: Verify that the query string fed to your signing service exactly matches what is sent to Binance — including parameter order, encoding, and the timestamp value. The signature must be generated from the exact query string bytes that will be sent. Check that you are using the API Secret (not the API Key) as the HMAC key. Test your signing service independently by computing a known HMAC and comparing against Binance's test vectors in their API documentation.

## Frequently asked questions

### Does Bubble's API Connector solve the Binance CORS problem?

Yes, completely. Binance blocks all browser-origin requests due to CORS policy. Bubble's API Connector runs server-side — requests go from Bubble's servers, not from the user's browser. CORS restrictions do not apply to server-to-server requests. You do not need a proxy or any special configuration to 'bypass' CORS — just use the API Connector normally and CORS is automatically a non-issue.

### What is Binance's weight system and why does it matter?

Each Binance API endpoint has a 'weight' value representing its computational cost. Your API key is allowed 1,200 weight units per minute. Simple endpoints like ticker/price cost 1 weight; depth endpoint with many levels costs up to 50 weight. Exceeding 1,200 weight/minute triggers a 429 error and a temporary IP ban. For a Bubble app refreshing prices every 30 seconds for one user, this is trivially within limits. For a high-traffic app with many concurrent users, monitor your weight consumption and consider database caching.

### Can I place trades on Binance from a Bubble app?

Technically yes, but it requires significant additional infrastructure. Order placement uses the POST /api/v3/order endpoint, which requires HMAC-SHA256 per-request signing that Bubble cannot compute natively. You need an external signing service (e.g. a Cloudflare Worker) that computes the signature, called from a Bubble Backend Workflow (paid plan). Additionally, your API key needs Spot Trading permissions enabled. For most Bubble builders, this complexity is better spent on a read-only portfolio display using Plaid instead.

### What is the Binance testnet and how do I use it?

The Binance testnet is a simulated trading environment at testnet.binance.vision. It has the same API structure as production but operates with virtual funds — no real money. To use it, go to testnet.binance.vision, log in with GitHub, and generate testnet API keys (separate from your production keys). In Bubble's API Connector, change the base URL to https://testnet.binance.vision and use your testnet keys. This lets you test price displays, order placement workflows, and error handling with zero financial risk.

### Why do I need a paid Bubble plan for Binance private endpoints?

Private Binance endpoints (account balances, trade history, order placement) require HMAC-SHA256 signature computation on every request. The signing workflow involves: calling an external signing service, receiving the computed signature, then calling Binance with all parameters. This multi-step process requires Backend Workflows (API Workflows), which are a paid Bubble feature. The free plan cannot run Backend Workflows. For public market data endpoints (price tickers, charts), the free plan works fine.

---

Source: https://www.rapidevelopers.com/bubble-integrations/binance-api
© RapidDev — https://www.rapidevelopers.com/bubble-integrations/binance-api