Gửi lệnh từ TradingView lên Binance/Bybit bằng API: hướng dẫn 2026

Nhận được tín hiệu từ TradingView mới chỉ là nửa đầu của câu chuyện. Nửa còn lại — và là nửa dễ mất tiền hơn — là đưa tín hiệu đó thành một lệnh thật trên sàn: đúng khối lượng, đúng bước giá, có stop loss, không bị sàn từ chối vì lỗi định dạng, và không bắn lệnh hai lần khi mạng chập chờn.

Bài viết này đi thẳng vào phần đó: tạo API key đúng quyền, phân biệt spot và futures, lọc tick size / step size (nguyên nhân số một khiến lệnh bị từ chối), code đặt lệnh market kèm SL/TP cho Binance Futures và Bybit v5, xử lý rate limit và lỗi API, đo slippage và phí để biết chiến lược có thực sự còn lãi khi chạy thật.

Đọc trước nếu bạn chưa dựng phần nhận tín hiệu: Bot Python nhận webhook TradingView và Tạo Alert TradingView gửi Webhook JSON.

Trả lời nhanh

Để gửi lệnh từ TradingView lên Binance hoặc Bybit, bạn cần ba thứ: một API key có quyền giao dịch futures/spot (không bật quyền rút tiền), một hàm đặt lệnh đã làm tròn giá và khối lượng theo đúng bộ lọc của symbol, và một lớp xử lý lỗi để phân biệt lỗi tạm thời (thử lại được) với lỗi vĩnh viễn (phải dừng).

Với Binance USD-M Futures, endpoint đặt lệnh là POST /fapi/v1/order (thư viện python-binance: futures_create_order). Với Bybit v5, endpoint là POST /v5/order/create với category=linear, và bạn có thể gửi luôn stopLoss/takeProfit trong cùng request.

Nguyên nhân phổ biến nhất khiến lệnh bị từ chối không phải là thiếu tiền, mà là sai bước giá hoặc sai bước khối lượng — ví dụ gửi 0.00013 BTC khi symbol yêu cầu bội số của 0.0001. Luôn lấy bộ lọc từ exchangeInfo (Binance) hoặc instruments-info (Bybit) rồi làm tròn trước khi gửi.

Điều cuối cùng cần nhớ: chạy được lệnh không có nghĩa là có lãi. Phí (taker ~0,04–0,055%/lệnh) cộng slippage có thể ăn hết biên lợi nhuận của một chiến lược khung 5 phút. Hãy đo hai con số này trước khi tăng khối lượng.

Chọn sàn nào cho bot webhook?

Cả Binance và Bybit đều dùng được; khác biệt nằm ở chi tiết vận hành.

Khuyến nghị thực dụng: nếu bạn mới bắt đầu và muốn ít lỗi vặt, Bybit v5 dễ chịu hơn vì gửi được SL/TP ngay trong lệnh vào. Nếu bạn cần thanh khoản sâu và nhiều altcoin, Binance USD-M là lựa chọn chính. Tốt nhất là viết lớp adapter (như bài 3) để có thể đổi sàn mà không phải viết lại logic.

Tạo API key đúng cách

Đây là bước quyết định an toàn của toàn hệ thống. Nguyên tắc: key của bot không bao giờ được có quyền rút tiền.

Với Binance:

1. Bật 2FA cho tài khoản trước khi tạo key.
2. Tạo một key riêng cho bot, tên rõ ràng (ví dụ bot-tv-webhook-v1).
3. Bật Enable Futures (hoặc Spot, tuỳ thị trường bạn giao dịch).
4. Không bật Enable Withdrawals, không bật Internal Transfer.
5. Bật Restrict access to trusted IPs only và thêm IP của VPS. Nếu bạn phát triển ở máy nhà, hãy dùng một key riêng cho môi trường dev.
6. Kiểm tra IP whitelist sau khi VPS đổi IP — đây là nguyên nhân phổ biến của lỗi -2015 Invalid API-key, IP, or permissions for action.

Với Bybit:

1. Tạo key trong API Management, chọn System-generated API keys.
2. Quyền: Read-Write cho Contract/Unified Trading, không bật Withdraw.
3. Bật IP restriction, thêm IP VPS.
4. Ghi lại key/secret vào .env với quyền file hạn chế (chmod 600 trên Linux).

Ba thói quen cần có:

• Không dán key vào chat, vào gist, hay vào screenshot. Nếu đã lỡ dán, xoá key và tạo key mới.
• Tách key theo môi trường: dev, testnet, production — ba key khác nhau.
• Xoay vòng key định kỳ (3–6 tháng) và mỗi khi có người rời nhóm.

Nếu sàn hỗ trợ sub-account, hãy tạo một sub-account riêng cho bot với số dư vừa đủ. Đây là biện pháp an toàn rẻ nhất và hiệu quả nhất: kể cả khi mọi thứ đổ vỡ, thiệt hại có trần.

Spot hay Futures cho bot TradingView?

Đây là quyết định ảnh hưởng đến toàn bộ logic bot sau này.

Ba lưu ý thực chiến:

1. Đòn bẩy không phải là "rủi ro cao hơn" nếu bạn giữ khối lượng theo % tài khoản. Đòn bẩy chỉ quyết định số tiền ký quỹ bị khoá. Rủi ro thật nằm ở khối lượng và khoảng cách stop loss. Tuy nhiên đòn bẩy cao làm ngưỡng thanh lý gần giá vào hơn, nên hãy để đòn bẩy vừa phải (3x–5x) khi chạy bot.

2. Funding có thể ăn lợi nhuận. Nếu bot của bạn giữ vị thế qua nhiều phiên funding (mỗi 8 giờ), chi phí này có thể lớn hơn phí giao dịch. Hãy đo funding trung bình của cặp bạn giao dịch và tính vào kỳ vọng lợi nhuận.

3. Chế độ vị thế (one-way vs hedge) quyết định payload. Ở chế độ one-way, bạn chỉ gửi side. Ở chế độ hedge (dualSidePosition), bạn phải gửi thêm positionSide (LONG/SHORT) — thiếu trường này lệnh sẽ bị từ chối. Hãy chốt chế độ một lần rồi cấu hình bot theo đúng chế độ đó, và kiểm tra lại sau khi tạo tài khoản mới.

Lọc tick size và step size: nguyên nhân số 1 lệnh bị từ chối

Đây là phần quan trọng nhất của bài, và cũng là phần hầu hết ví dụ trên mạng bỏ qua.

Mỗi symbol trên sàn có hai ràng buộc định dạng:

• Tick size: bước giá nhỏ nhất. Ví dụ tick size 0.10 nghĩa là giá phải là bội số của 0,10 (2350,10 hợp lệ; 2350,13 không).
• Step size (lot size): bước khối lượng nhỏ nhất. Ví dụ 0.001 nghĩa là khối lượng phải là bội số của 0,001.

Ngoài ra còn có minQty (khối lượng tối thiểu) và minNotional (giá trị lệnh tối thiểu — thường 5 USDT trên Binance Futures).

from decimal import Decimal, ROUND_DOWN

def floor_to_step(value: float, step: str) -> Decimal:
    v, s = Decimal(str(value)), Decimal(str(step))
    return (v // s) * s

def round_price(price: float, tick: str) -> Decimal:
    t = Decimal(str(tick))
    p = Decimal(str(price))
    return (p / t).quantize(Decimal('1'), rounding=ROUND_DOWN) * t

# tick = "0.10", step = "0.001"
price = round_price(2387.37, "0.10")     # -> 2387.30
qty   = floor_to_step(0.01784, "0.001")  # -> 0.017

Ba điểm cần nhớ:

• Luôn làm tròn xuống, không làm tròn lên. Khối lượng làm tròn lên có thể vượt số dư khả dụng; giá làm tròn lên có thể đặt lệnh ngoài vùng cho phép.
• Dùng `Decimal`, không dùng `float`. Số thực nhị phân gây sai số kiểu 0.1 + 0.2 = 0.30000000000000004, đủ để lệnh bị từ chối.
• Cache bộ lọc theo symbol trong 1–6 giờ, đừng gọi exchangeInfo mỗi lệnh — nó rất nặng và ăn hết hạn mức request của bạn.

Sau khi làm tròn, luôn kiểm tra thêm ba điều kiện: khối lượng ≥ minQty, price × qty ≥ minNotional, và khối lượng sau làm tròn vẫn > 0. Bỏ qua bước này, bạn sẽ nhận hàng loạt lỗi -1111 Precision is over the maximum defined for this asset hoặc -4003 Quantity less than or equal to zero.

Code đặt lệnh market kèm SL/TP (Binance USD-M Futures)

from binance.client import Client
from binance.enums import SIDE_BUY, SIDE_SELL, ORDER_TYPE_MARKET
from binance.exceptions import BinanceAPIException

client = Client(os.environ["BINANCE_API_KEY"], os.environ["BINANCE_API_SECRET"])

def open_position(symbol: str, side: str, qty, sl: float | None, tp: float | None,
                  leverage: int = 5):
    # 1) đặt đòn bẩy (idempotent - gọi lại không sao)
    try:
        client.futures_change_leverage(symbol=symbol, leverage=leverage)
    except BinanceAPIException as e:
        log.warning("Không đổi được leverage %s: %s", symbol, e)

    # 2) lệnh vào market
    order = client.futures_create_order(
        symbol=symbol,
        side=SIDE_BUY if side == "buy" else SIDE_SELL,
        type=ORDER_TYPE_MARKET,
        quantity=float(qty),
        newOrderRespType="RESULT",
    )

    # 3) đặt SL và TP dạng STOP_MARKET, reduceOnly
    close_side = SIDE_SELL if side == "buy" else SIDE_BUY
    if sl:
        client.futures_create_order(symbol=symbol, side=close_side, type="STOP_MARKET",
            stopPrice=float(sl), closePosition=True, workingType="MARK_PRICE")
    if tp:
        client.futures_create_order(symbol=symbol, side=close_side, type="TAKE_PROFIT_MARKET",
            stopPrice=float(tp), closePosition=True, workingType="MARK_PRICE")
    return order

Bốn chi tiết quyết định sự an toàn của đoạn code này:

1. `newOrderRespType="RESULT"` — bạn cần biết giá khớp thật (avgPrice) để đo slippage và để đặt SL/TP đúng phía.
2. `closePosition=True` cho SL/TP — đóng toàn bộ vị thế khi giá chạm, không phụ thuộc khối lượng bạn tính. An toàn hơn reduceOnly + quantity trong trường hợp khớp một phần.
3. `workingType="MARK_PRICE"` — dùng giá đánh dấu thay vì giá last, tránh bị "quét" bởi biến động ngắn của giá last.
4. Kiểm tra kết quả từng bước. Nếu lệnh vào thành công nhưng đặt SL thất bại, bot phải cảnh báo ngay và có thể đóng vị thế nếu bạn chọn chính sách an toàn đó.

Lưu ý về chế độ hedge: nếu tài khoản ở chế độ dual-side, bạn bắt buộc thêm positionSide="LONG" hoặc "SHORT" vào mọi lệnh. Bỏ qua trường này sẽ nhận lỗi -4061 Order's position side does not match user's setting.

Code tương đương cho Bybit v5

from pybit.unified_trading import HTTP

session = HTTP(api_key=os.environ["BYBIT_API_KEY"], api_secret=os.environ["BYBIT_API_SECRET"])

def open_position_bybit(symbol: str, side: str, qty, sl: float | None, tp: float | None,
                        leverage: int = 5):
    session.set_leverage(category="linear", symbol=symbol,
                         buyLeverage=str(leverage), sellLeverage=str(leverage))

    return session.place_order(
        category="linear",
        symbol=symbol,
        side="Buy" if side == "buy" else "Sell",
        orderType="Market",
        qty=str(qty),
        stopLoss=str(sl) if sl else "",
        takeProfit=str(tp) if tp else "",
        tpslMode="Full",
        slTriggerBy="MarkPrice",
        tpTriggerBy="MarkPrice",
        timeInForce="IOC",
        reduceOnly=False,
    )

Bybit gọn hơn ở chỗ SL/TP nằm cùng request: hoặc lệnh vào thành công kèm SL/TP, hoặc thất bại cả cụm — tránh trạng thái "đã mở lệnh nhưng chưa có stop". Điểm cần chú ý: qty phải là chuỗi đã làm tròn theo qtyStep, và tpslMode="Full" nghĩa là SL/TP áp cho toàn bộ vị thế.

Nếu bạn gửi SL/TP ở request riêng (/v5/position/trading-stop), hãy nhớ rằng khoảng cách tối thiểu giữa giá vào và giá SL được sàn quy định theo bảng riêng cho từng cặp — vi phạm sẽ nhận retCode 10001 (params error).

Xử lý lỗi API: phân biệt lỗi tạm thời và lỗi vĩnh viễn

Đây là chỗ phân biệt bot "thử cho vui" với bot chạy tiền thật. Nguyên tắc: thử lại chỉ khi lỗi có thể tự khỏi, và mọi lần thử lại phải idempotent.

Điểm khó nhất là nhóm lỗi timeout. Khi request timeout, bạn không biết lệnh đã được đặt hay chưa. Nếu cứ thử lại, bạn có nguy cơ mở hai vị thế. Cách xử lý đúng:

1. Trước khi thử lại, gọi API truy vấn lệnh gần nhất theo symbol (Binance: futures_get_all_orders, Bybit: get_open_orders + get_order_history).
2. Nếu thấy lệnh với clientOrderId của bạn (xem mục dưới) → không thử lại, xử lý như đã thành công.
3. Nếu trong 5–10 giây không tìm thấy → mới thử lại.

Luôn gửi `clientOrderId` (Binance) hoặc `orderLinkId` (Bybit) do bot tự sinh, dạng <strategy>-<symbol>-<timestamp>. Đây là chìa khoá để tra cứu, chống trùng và đối soát. Không có nó, mọi nỗ lực "thử lại an toàn" đều là đoán mò.

Rate limit: tránh bị khoá IP

Binance tính trọng số (weight) cho mỗi endpoint và có ba ngưỡng: warn, 429 (quá nhanh), 418 (bị cấm tạm). Bybit tính theo số request/giây cho mỗi key/endpoint.

Bốn cách giảm tải đáng làm ngay:

1. Cache bộ lọc symbol (exchangeInfo) 1–6 giờ — đây là request nặng nhất trong luồng của bạn.
2. Dùng WebSocket để theo dõi vị thế và giá, chỉ dùng REST để đặt/huỷ lệnh. Đừng polling số dư mỗi giây.
3. Gộp lệnh: nếu cần vào nhiều cặp, kiểm tra xem sàn có endpoint batch (Bybit có /v5/order/create-batch).
4. Xếp hàng ở phía bot: một worker xử lý tuần tự, hoặc giới hạn N request/giây ở tầng gọi API.

Khi bị 429, hãy tôn trọng header `Retry-After` nếu có và áp dụng exponential backoff. Nếu bị 418, dừng gửi lệnh ít nhất vài phút — cố gửi tiếp sẽ làm thời gian bị cấm dài hơn.

Đo slippage và phí: chiến lược của bạn có thực sự còn lãi?

Sau vài trăm lệnh, bạn cần ba con số để biết bot có đáng chạy tiếp:

1. Slippage trung bình mỗi lệnh. So giá tín hiệu trong payload với avgPrice thật.

slip = (order["avgPrice"] - signal_price) / signal_price * (1 if side == "buy" else -1)

Với XAUUSD khung 15m, slippage 0,02–0,05% là bình thường. Với altcoin thanh khoản thấp, có thể lên 0,3% — đủ để phá một chiến lược biên mỏng.

2. Phí mỗi lệnh (khứ hồi). Lệnh market ở cả hai đầu = taker hai lần. Crypto futures thường 0,04–0,055% mỗi chiều, tức 0,08–0,11%/lệnh khứ hồi. Nếu chiến lược của bạn kiếm 0,15%/lệnh, bạn còn không tới 0,05% trước khi tính slippage.

3. Funding (nếu giữ vị thế qua nhiều phiên). Cộng dồn vào chi phí. Bot giữ vị thế 3 ngày có thể trả funding 6–9 lần.

# lợi nhuận ròng thực tế mỗi lệnh
net = (exit_price - entry_price) / entry_price \
      - fee_taker * 2 - slippage_pct - funding_pct

Hãy đưa ba con số này vào báo cáo hằng ngày. Khi bạn tăng khối lượng gấp 5, slippage thường tăng (không tuyến tính), nên đo lại sau mỗi lần tăng size.

Nhật ký lệnh và đối soát

Mọi lệnh phải để lại một bản ghi có thể tra cứu. Trường tối thiểu:

{"trace_id":"tv-20261006-15m-0007","symbol":"BTCUSDT","side":"buy","qty":"0.017",
 "signal_price":68120.5,"fill_price":68147.1,"slippage_pct":0.00039,
 "fee":"0.52","sl":67800.0,"tp":68850.0,"strategy":"hull-rsi","status":"filled",
 "client_order_id":"hullrsi-BTCUSDT-1759731200"}

Ba tháng sau, khi bạn muốn biết "vì sao ngày hôm đó lỗ 4%", nhật ký này là thứ duy nhất trả lời được. Log kiểu "đã đặt lệnh buy BTCUSDT" không giúp gì cả.

Song song với nhật ký, hãy chạy đối soát định kỳ — mỗi 1–5 phút so vị thế đang mở thực tế ở sàn với sổ log. Chênh lệch không tự khỏi; chúng chỉ tích tụ cho tới khi thành vấn đề lớn.

Chuyển từ testnet sang tiền thật: quy trình 5 bước

1. Chạy testnet ít nhất 3 ngày với chiến lược thật. Testnet của Binance/Bybit có thanh khoản khác bản thật, nên nó kiểm tra logic chứ không kiểm tra slippage.
2. Chuyển sang tài khoản thật với khối lượng tối thiểu (đúng bằng minNotional) trong 3–7 ngày. Mục tiêu: xác nhận luồng lệnh, log, cảnh báo hoạt động.
3. Tăng dần theo cấp (ví dụ ×2 mỗi tuần) chỉ khi báo cáo không có lệnh lỗi và slippage ổn định.
4. Đo lại slippage và phí sau mỗi lần tăng size — đây là lúc chiến lược dễ "đổi tính" nhất.
5. Chốt trần rủi ro: số vị thế tối đa, % rủi ro mỗi lệnh, trần lỗ ngày, trần lỗ tuần. Trần lỗ tuần là thứ bảo vệ bạn khỏi chuỗi thua liên tiếp.

Một lưu ý về tâm lý: giai đoạn đầu chạy tiền thật, bạn sẽ muốn tắt bot mỗi khi thấy lệnh lỗ. Hãy đặt trước quy tắc "chỉ can thiệp khi vi phạm trần rủi ro" và ghi lại mọi lần can thiệp — để sau này bạn biết cảm xúc của mình đã làm mất bao nhiêu tiền.

Checklist trước khi bật giao dịch thật

1. ✅ API key chỉ có quyền giao dịch, IP whitelist đã bật.
2. ✅ Đã lấy và cache bộ lọc tickSize, stepSize, minQty, minNotional.
3. ✅ Làm tròn bằng Decimal, luôn làm tròn xuống.
4. ✅ Có clientOrderId/orderLinkId cho mọi lệnh.
5. ✅ Đã biết chế độ vị thế (one-way/hedge) và gửi đúng positionSide nếu cần.
6. ✅ SL/TP luôn được đặt, và có kiểm tra kết quả đặt.
7. ✅ Có xử lý lỗi phân loại: không thử lại lỗi vĩnh viễn, thử lại có kiểm tra với timeout.
8. ✅ Có trần số vị thế, trần lỗ ngày, trần lỗ tuần.
9. ✅ Có nhật ký lệnh ghi slippage, phí, funding.
10. ✅ Đã đo lợi nhuận ròng sau phí + slippage trên ít nhất 100 lệnh thật.

Nếu chỉ chọn được 3 điểm để làm trước, hãy chọn điểm 2, 6 và 10. Sai bộ lọc làm lệnh không vào được; thiếu SL làm rủi ro không kiểm soát; không đo ròng thì bạn không biết mình đang lãi hay lỗ.

Những khác biệt giữa backtest và chạy thật trên sàn crypto

Đây là bốn thứ mà mô phỏng trên TradingView không bao giờ tái hiện đúng, và là lý do nhiều chiến lược "đẹp trên giấy" lại lỗ khi chạy:

1. Funding rate. Futures crypto trả/nhận funding mỗi 8 giờ. Nếu chiến lược của bạn giữ vị thế nhiều ngày, đây là dòng chi phí thật, có lúc lên tới 0,1%/phiên — tương đương 0,3%/ngày. Hãy theo dõi funding lịch sử của cặp bạn giao dịch trước khi quyết định giữ lệnh qua đêm.

2. Thanh lý (liquidation) và biên độ biến động thật. Backtest chỉ nhìn giá đóng nến; thực tế giá có thể giật mạnh trong nến và chạm ngưỡng thanh lý trước khi quay lại. Với bot chạy đòn bẩy, một cú "wick" đủ dài có thể xoá vị thế mà SL của bạn chưa từng kích hoạt theo logic bạn mô phỏng.

3. Bộ lọc và quy định của sàn thay đổi. Sàn có thể điều chỉnh tickSize, stepSize, minNotional, phí, hoặc bảo trì. Bot phải lấy bộ lọc định kỳ (cache có thời hạn) chứ không hardcode, và phải chịu được việc một symbol tạm ngừng giao dịch.

4. Thanh khoản theo thời điểm. Cùng một lệnh, slippage lúc 15h00 (phiên Âu–Mỹ) khác hoàn toàn lúc 3h00 sáng. Nếu bot của bạn vào lệnh 24/7, hãy tách số liệu slippage theo khung giờ — bạn có thể phát hiện ra rằng chiến lược chỉ hiệu quả trong 6 giờ nhất định.

Cách xử lý cả bốn vấn đề này rất đơn giản: ghi lại và đo. Một tuần dữ liệu thật cho bạn câu trả lời chính xác hơn mọi suy đoán.

Playbook xử lý sự cố trong 60 giây

Khi có cảnh báo, bạn cần biết làm gì ngay — không phải đọc lại code. Đây là thứ tự kiểm tra:

Tình huống 1 — Không thấy tín hiệu nào trong nhiều giờ.

Kiểm tra theo thứ tự: bot còn sống (heartbeat) → endpoint truy cập được từ ngoài → chứng chỉ HTTPS còn hạn → alert còn bật trong TradingView và ô Webhook URL vẫn còn. Trong 90% trường hợp lỗi nằm ở một trong bốn điểm này.

Tình huống 2 — Lệnh vào nhưng thiếu SL.

Đây là tình huống nguy hiểm nhất. Việc đầu tiên: đặt SL bằng tay trên app sàn để có bảo vệ tạm thời. Sau đó kiểm tra log xem lỗi đặt SL là gì (thường là sai khoảng cách tối thiểu hoặc positionSide). Đừng để vị thế qua đêm mà không có stop.

Tình huống 3 — Bot vào 2–3 lệnh cho cùng tín hiệu.

Dừng bot ngay (không phải dừng sàn), đóng các lệnh dư theo quy tắc bạn chọn, rồi kiểm tra khoá chống trùng. Nếu bạn chạy nhiều worker mà chống trùng bằng biến RAM, đây chính là nguyên nhân — chuyển khoá sang Redis hoặc database.

Tình huống 4 — Sàn trả lỗi liên tục (429/418 hoặc rate limit).

Giảm tần suất gọi API, bật backoff, và kiểm tra xem bạn có đang gọi exchangeInfo mỗi lệnh không. Nếu bị 418, dừng gửi lệnh vài phút thay vì cố gửi tiếp.

Tình huống 5 — Số dư không khớp giữa bot và sàn.

Chạy đối soát thủ công: liệt kê vị thế thật, liệt kê sổ log, so từng cái. Ghi lại khác biệt với cờ unmanaged cho những vị thế bạn vào tay. Không tự động đóng những vị thế bot không tạo ra.

In playbook này ra và dán cạnh máy. Khi có sự cố bạn sẽ không muốn phải suy nghĩ — chỉ muốn làm theo bước.

Tổng kết

Đưa tín hiệu TradingView lên Binance/Bybit không khó về mặt API — nó chỉ có nhiều chi tiết nhỏ mà bỏ sót cái nào cũng trả giá:

• API key tối thiểu quyền, IP whitelist, tách môi trường.
• Làm tròn theo tick size và step size bằng Decimal, cache bộ lọc.
• SL/TP luôn được đặt, có kiểm tra kết quả, ưu tiên closePosition/tpslMode=Full.
• Xử lý lỗi phân loại và dùng clientOrderId để thử lại an toàn.
• Đo slippage + phí + funding để biết chiến lược còn lãi hay chỉ lãi trên giấy.

Với bốn thứ trên, phần còn lại chỉ là vận hành: chạy 24/7, giám sát, đối soát.

Muốn dựng trọn chuỗi này với người hướng dẫn từng buổi — từ tín hiệu TradingView tới lệnh thật trên MT5, Binance/Bybit và chứng khoán Việt Nam — Bootcamp TradingView Webhook Bot gồm 6 buổi online (20:00–22:00 Thứ 2, khai giảng 19/10/2026), học phí 990.000đ, tặng kèm 12 tháng FindMe VPS Guardian.

Đọc tiếp trong cụm bài:

• TradingView Webhook là gì? Hướng dẫn A–Z
• Tạo Alert TradingView gửi Webhook JSON
• Bot Python nhận webhook TradingView (Flask)
• Khóa Lập trình Bot Auto Trading không cần biết code

Câu hỏi thường gặp

Tôi cần bật quyền gì khi tạo API key cho bot?

Chỉ quyền giao dịch (Futures hoặc Spot tuỳ thị trường bạn chạy) và đọc dữ liệu. Tuyệt đối không bật quyền rút tiền (Withdrawals) hay chuyển nội bộ. Nên bật IP whitelist để key chỉ dùng được từ VPS của bạn.

Vì sao lệnh của tôi bị từ chối dù tín hiệu đúng?

Nguyên nhân phổ biến nhất là sai bước giá (tick size) hoặc bước khối lượng (step size). Nguyên nhân thứ hai là khối lượng nhỏ hơn minQty hoặc giá trị lệnh nhỏ hơn minNotional. Hãy lấy bộ lọc từ exchangeInfo/instruments-info và làm tròn xuống bằng Decimal trước khi gửi.

Nên dùng spot hay futures cho bot?

Nếu chiến lược của bạn chỉ mua (long) và bạn muốn đơn giản, dùng spot. Nếu cần bán khống, dùng futures với đòn bẩy vừa phải (3x–5x) và luôn giữ khối lượng theo % rủi ro. Futures có thêm chi phí funding và nguy cơ thanh lý nếu đòn bẩy quá cao.

Khi request bị timeout, làm sao biết lệnh đã vào hay chưa?

Đừng thử lại ngay. Hãy tra lệnh theo clientOrderId (Binance) hoặc orderLinkId (Bybit) qua API truy vấn lệnh. Nếu tìm thấy thì coi như đã thành công; nếu sau 5–10 giây vẫn không thấy mới thử lại. Đây là lý do bạn phải tự sinh clientOrderId cho mọi lệnh.

Vì sao tôi nhận lỗi -4061 (position side không khớp)?

Tài khoản của bạn đang ở chế độ hedge (dual-side), và mọi lệnh bắt buộc phải gửi thêm positionSide="LONG" hoặc "SHORT". Hoặc bạn đã gửi positionSide trong khi tài khoản đang ở chế độ one-way. Hãy kiểm tra chế độ vị thế trong cài đặt API/tài khoản và cấu hình bot theo đúng chế độ đó.

Làm sao biết chiến lược còn lãi sau khi tính phí?

Đo ba con số: slippage trung bình (so giá tín hiệu với avgPrice thật), phí khứ hồi (taker hai lần, thường 0,08–0,11% với futures crypto), và funding nếu giữ vị thế qua nhiều phiên. Lợi nhuận ròng = biến động giá − phí − slippage − funding. Nếu biên lợi nhuận mỗi lệnh nhỏ hơn 0,15%, chiến lược thường không sống được sau chi phí.

Có nên đặt đòn bẩy cao để dùng ít vốn không?

Không nên. Đòn bẩy cao làm ngưỡng thanh lý gần giá vào hơn, nên chỉ cần một cú giật ngắn là vị thế bị đóng trước khi SL của bạn kịp chạm. Rủi ro thật nằm ở khối lượng và khoảng cách stop loss, không nằm ở đòn bẩy — nên hãy để đòn bẩy vừa phải và tính khối lượng theo % rủi ro.

Rate limit của sàn là bao nhiêu và làm sao tránh bị khoá?

Binance tính theo trọng số của từng endpoint và trả 429 (quá nhanh) rồi 418 (bị cấm tạm) khi vượt ngưỡng; Bybit giới hạn số request/giây mỗi key. Cách tránh: cache exchangeInfo, dùng WebSocket thay vì polling để theo dõi giá/vị thế, gộp lệnh bằng endpoint batch nếu có, và áp dụng backoff khi gặp 429.