Getting started with Bitget on Autoview
By the end of this guide your Bitget account is connected to Autoview, all three credentials are in place, and you've fired one real test order and cancelled it. That last part matters. A dry run tells you your syntax parses. Only a live order tells you the whole chain works.
Bitget is different from most exchanges Autoview connects to. The key comes in three parts, not two. Get all three right and the rest is easy.
What Autoview does
Autoview runs a webhook on our servers. An alert fires, the webhook receives a command, and Autoview places the matching order on Bitget. It runs around the clock and doesn't care where the alert came from. TradingView is the common source, but a TrendSpider alert, a Python script, or your own cron job can POST the same command and get the same result.
You connect Bitget by handing Autoview a set of API credentials. The credentials let Autoview place and manage orders on your account without ever seeing your password. You generate them inside Bitget, then paste them into Autoview.
Create your API key on Bitget
Sign in to Bitget, open the user menu, and go to API Management. Create a new API key. Bitget keeps its own walkthrough current, so follow theirs for the exact clicks: Bitget API documentation.
Two rules are non-negotiable when you create the key:
- Grant trade permission. Autoview needs to place and cancel orders and read your balances and positions. Without trade permission, nothing executes.
- Never grant withdrawal permission. No automation strategy needs it. A key that can't move funds off the exchange is a key that can't drain your account if it leaks.
Bitget asks you to set a passphrase of your own when you create the key. Write it down exactly as you type it, capital letters and all. This is not your account password. It's a separate secret tied to this one key, and Autoview needs it as a third field.
Bitget shows the secret key once, at creation. Copy all three values before you leave that screen: the API key, the secret key, and the passphrase you chose. There's no recovering the secret later. You'd just delete the key and make a new one.
Add the keys to Autoview
Open your Bitget configuration in Autoview. You'll see three fields, and the labels match what Bitget gave you:
- Access API Key. The API key Bitget generated.
- Secret Key. The secret shown once at creation.
- Passphrase. The passphrase you set yourself.
Paste each value into its matching field. The most common Bitget setup failure is a wrong or forgotten passphrase, so double-check that one. Test the connection, then save, and watch for the confirmation that the account connected.
Fire a dry run, then a live test
This is the step people skip, and then they wonder at 3am why a live signal did nothing. Don't skip it.
Start with a dry run. Add d=1 to any command and Autoview parses it, shows you exactly what it would have done, and sends nothing to Bitget. A clean dry run confirms your syntax before any money moves.
Bitget uses its own symbol codes, and the spot market wants the pair concatenated. Bitcoin against USDT is BTCUSDT. Check the exact code on Bitget for any pair you trade. A spot limit buy 5% under the market, sent through your webhook, looks like this:
s=BTCUSDT b=buy p=-5% q=1 d=1
Read the dry-run output. When it matches what you meant, drop the d=1 and send it live. The cleanest trigger is a single-fire alert on an active market; a condition like "price greater than 0" fires almost instantly.
A warning before you send anything live: these commands hit your real Bitget account. Trade a size at or above Bitget's minimum for the pair, and set a limit price far enough from the market that it won't fill while you're testing.
The example above hard-codes a price offset and a quantity, which is what you want for a controlled test. In live use you'll often want a real value instead. A TradingView alert can write one in: p={{close}} tells TradingView to substitute the candle's close at fire time, and Autoview receives a plain number. The {{close}} token is TradingView's, not Autoview's. The alert sender supplies the value, so a Python script or another platform builds the same command its own way and posts a number where {{close}} would sit.
Fire it, then open the Autoview log and your Bitget orders. You should see the resting limit order in both. Now cancel it with the same symbol:
s=BTCUSDT b=buy c=order
Order placed, order cancelled, both confirmed on Bitget. That's the full round trip. Your setup works.
Check the cancel on Bitget, not only in the log (as of October 4, 2026). A review of Autoview's Bitget code against Bitget's API docs found that a spot cancel that works may still be logged by Autoview as an error. If your Bitget open orders no longer show the test order, the cancel worked, whatever the log says. This comes from reading the code and hasn't been confirmed on a live account.
Go live: spot, futures, and copy trading
One Bitget connection drives three markets. Which one a command hits depends on the exchange code you route it to. On the webhook platform the webhook already knows its exchange, so you set this once when you wire up the webhook rather than typing it on every command.
- Spot trades route to
bitget. - Futures (Bitget's mix contracts) route to
bitget-mix. Futures commands accept leverage withl=, plus stop-loss, take-profit, and trailing parameters. - Copy trading: to close a copy-trade position, route to
bitget-mix-copy.
Two caveats, as of October 4, 2026, from a review of Autoview's Bitget code against Bitget's API docs. Neither has been confirmed on a live account yet, and this page will change when they're settled.
- Copy-trade close: the review found that
bitget-mix-copyreads the position's average price under a field name Bitget doesn't use, so a close is likely to report that no position was found. Watch your first close on Bitget itself, and be ready to close the position there by hand. - Futures trigger orders: stop-loss and take-profit attached to a trigger order are likely to be dropped, and a limit trigger order is likely to be rejected. A trailing stop sent without
t=marketprobably fails too. Dry-run the command withd=1, then check the result on Bitget before you rely on it.
All three use the same three credentials you already entered. The futures and copy-trade codes don't need a second key, only the right route.
Symbol and minimum-size checks before you send anything real
Bitget doesn't take a fixed size or price from Autoview. Before it builds your order, Autoview pulls that symbol's own precision and step size straight from Bitget's exchange-info endpoint, quantity precision for sizing, price step and price precision for your limit price, and rounds your command to match. A quantity or price that doesn't fit a listed symbol's rules gets rejected by Bitget itself, not silently accepted at the wrong size. If a live order comes back rejected on size, check the pair's minimum on Bitget directly; Autoview's d=1 dry run shows you the exact rounded values it resolved before anything goes out.
Connected and tested? Good. Next you'll want stop-loss, take-profit, and trailing parameters layered onto your futures commands through bitget-mix. That's where the automation starts earning its keep.