Nhận webhook TradingView bằng Python (Flask)

Server nhận webhook là nửa còn lại của một TradingView Webhook Bot. Phần này không cần phức tạp, nhưng cần được viết đúng ngay từ đầu, vì mọi lỗi ở đây đều liên quan trực tiếp tới tiền. Bài viết đi từ đoạn code ngắn nhất có thể chạy được tới phiên bản đủ dùng cho tiền thật.

Kiến trúc tối thiểu của server nhận webhook

Một server nhận webhook thực chất chỉ làm năm việc: nhận request, xác thực, chống trùng, quyết định, và thực thi. Mọi thứ khác như giao diện hay biểu đồ đều là tuỳ chọn.

Năm việc này nên nằm ở năm hàm riêng, dù ban đầu bạn viết tất cả trong một file. Lý do là khi cần gỡ lỗi, bạn sẽ muốn biết lỗi nằm ở bước nào. Nếu tất cả nằm trong một hàm dài, mọi lỗi đều trông giống nhau.

Kiến trúc gọn nhất thường gồm bốn tệp: tệp cấu hình đọc biến môi trường, tệp thực thi giao dịch của sàn, tệp xử lý logic tín hiệu, và tệp chạy server. Cách chia này giúp bạn đổi sàn mà không phải sửa phần nhận webhook, và đổi cách nhận webhook mà không phải sửa phần giao dịch.

Chọn framework: Flask, FastAPI hay serverless

Ba lựa chọn phổ biến, mỗi lựa chọn có một đánh đổi rõ ràng.

Flask là lựa chọn dễ nhất cho người mới. Code ngắn, ít khái niệm, chạy được ở mọi nơi, tài liệu nhiều. Nhược điểm là bạn phải tự lo phần chạy nền và phần chạy ở chế độ sản xuất.

FastAPI mang lại kiểm tra kiểu dữ liệu và hỗ trợ bất đồng bộ. Nếu bạn quen với khái niệm hàm bất đồng bộ thì đây là lựa chọn rất tốt. Nếu chưa quen, bạn sẽ mất thêm thời gian học những thứ không liên quan tới mục tiêu chính là đặt lệnh.

Serverless phù hợp khi bạn không muốn quản trị máy chủ. Đánh đổi là khó giữ trạng thái dài hạn, dễ gặp tình trạng nguội hàm gây chậm lần gọi đầu, và việc gỡ lỗi khó hơn vì khó xem log trực tiếp.

Lựa chọn	Độ dễ cho người mới	Kiểm soát	Phù hợp với
Flask trên VPS	Cao	Cao	bot cá nhân, chạy 24/7
FastAPI trên VPS	Trung bình	Cao	nhiều tín hiệu, cần async
Serverless	Trung bình	Thấp	tín hiệu thưa, không muốn quản máy

Đoạn code ngắn nhất nhận được webhook

Bắt đầu bằng phiên bản chỉ ghi log, chưa đặt lệnh. Cách này giúp bạn tách vấn đề: nếu tin nhắn không tới được đây thì vấn đề nằm ở phía TradingView, không phải ở phía bot.

from flask import Flask, request, jsonify

app = Flask(__name__)


@app.post("/tv-webhook")
def tv_webhook():
    payload = request.get_json(silent=True) or {}
    print("NHAN DUOC:", payload, flush=True)
    return jsonify({"ok": True}), 200


if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

Chạy file này trên VPS, mở cổng, đặt một lớp HTTPS phía trước, tạo alert trong TradingView trỏ tới địa chỉ đó, và chờ xem log có dòng in ra hay không. Khi đã thấy nội dung in ra đúng như bạn soạn trong ô message, bạn đã đi qua phần khó nhất về hạ tầng.

Xác thực khoá bí mật

Giữ bí mật đường dẫn là bảo mật yếu. Bất kỳ ai đọc được log hoặc xem ảnh chụp màn hình cấu hình của bạn đều có thể gửi lệnh giả vào tài khoản bạn. Vì vậy hãy thêm một khoá bí mật và kiểm tra nó ở mọi request.

import os
from flask import request, jsonify, abort

SECRET = os.environ["TV_WEBHOOK_SECRET"]


def verify(payload: dict) -> None:
    if payload.get("secret") != SECRET:
        abort(401)

Ba lưu ý khi dùng cách này. Một là so sánh khoá bằng phép so sánh an toàn tránh rò rỉ thời gian, nếu bạn muốn kỹ hơn. Hai là không đặt khoá trong code mà đọc từ biến môi trường, để khi commit lên kho mã nguồn bạn không vô tình công bố khoá. Ba là nếu khoá bị lộ, chỉ cần đổi biến môi trường và cập nhật lại alert, không phải đổi hạ tầng.

Ngoài khoá bí mật, hai lớp bảo vệ nữa rất đáng làm. Thứ nhất là giới hạn kích thước request, ví dụ vài kilobyte, để tránh ai đó gửi payload khổng lồ làm treo server. Thứ hai là giới hạn tần suất theo địa chỉ nguồn, để tránh bị dội tin nhắn.

Trả về 200 ngay, xử lý sau

Đây là chi tiết kỹ thuật quan trọng nhất trong toàn bộ bài, và cũng là chi tiết người mới hay làm sai.

Nếu bạn gọi API sàn ngay trong hàm xử lý request và chỉ trả về sau khi lệnh đã được đặt, thì thời gian phản hồi của bạn bằng tổng thời gian gọi API sàn. Trong điều kiện thị trường biến động, API sàn có thể chậm, và phản hồi chậm có thể bị coi là thất bại. Khi đó bạn đối mặt với một tình huống rất khó: không biết lệnh đã được đặt hay chưa.

Cách làm đúng là tách hai giai đoạn. Giai đoạn một, khi nhận request, server xác thực, chống trùng, lưu payload vào hàng đợi, rồi trả về ngay. Giai đoạn hai, một luồng riêng đọc hàng đợi và gọi API sàn. Nhờ vậy thời gian phản hồi với TradingView luôn ở mức vài mili giây, và mọi việc nặng được xử lý với log đầy đủ.

Trong Flask, hàng đợi có thể chỉ là một hàng đợi trong bộ nhớ nếu bạn chạy một tiến trình. Nếu chạy nhiều tiến trình, hãy dùng hàng đợi bền vững hơn hoặc một cơ sở dữ liệu nhỏ.

Chống trùng lệnh bằng mã tín hiệu

Cơ chế chống trùng đơn giản nhưng hiệu quả: lưu mã tín hiệu của mỗi payload đã xử lý, kèm thời gian sống. Nếu mã đã tồn tại, bỏ qua.

import time

SEEN: dict[str, float] = {}
TTL = 3600


def already_seen(signal_id: str) -> bool:
    now = time.time()
    expired = [k for k, t in SEEN.items() if now - t > TTL]
    for k in expired:
        SEEN.pop(k, None)
    if signal_id in SEEN:
        return True
    SEEN[signal_id] = now
    return False

Với bot cá nhân, từ điển trong bộ nhớ là đủ. Với bot chạy nhiều tiến trình hoặc cần giữ trạng thái khi khởi động lại, hãy dùng Redis hoặc một bảng trong cơ sở dữ liệu.

Thời gian sống nên lớn hơn khoảng cách giữa hai tín hiệu hợp lệ gần nhau nhất, nhưng nhỏ hơn khoảng thời gian mà việc bỏ sót tín hiệu trở nên nghiêm trọng. Với chiến lược khung 15 phút, đặt thời gian sống khoảng một tới vài giờ là hợp lý.

Nối vào sàn: ví dụ với Binance

Với crypto, phần thực thi thường gọn nhất vì khớp lệnh tức thì và API rõ ràng.

Ba việc cần làm: đọc API key và secret từ biến môi trường, làm tròn khối lượng theo bước khối lượng mà sàn quy định, và đặt lệnh kèm dừng lỗ nếu chiến lược yêu cầu.

Một đoạn code minh hoạ cách tiếp cận:

import os
import ccxt

exchange = ccxt.binance({
    "apiKey": os.environ["BINANCE_KEY"],
    "secret": os.environ["BINANCE_SECRET"],
    "options": {"defaultType": "spot"},
})


def market_buy(symbol: str, quote_amount: float) -> dict:
    exchange.load_markets()
    price = exchange.fetch_ticker(symbol)["last"]
    raw_qty = quote_amount / price
    amount = exchange.amount_to_precision(symbol, raw_qty)
    return exchange.create_market_buy_order(symbol, float(amount))

Ba điểm cần chú ý trong đoạn trên. Một là mã cặp phải đúng định dạng của sàn, ví dụ BTCUSDT với sàn giao ngay. Hai là khối lượng phải được làm tròn theo bước của sàn, nếu không sàn sẽ từ chối. Ba là nên tải danh sách thị trường một lần rồi lưu lại, thay vì tải ở mọi request, để giảm độ trễ và tránh bị giới hạn tần suất.

Với hợp đồng tương lai, bạn cần thêm các bước như đặt chế độ ký quỹ, chọn đòn bẩy và đảm bảo chế độ vị thế đúng. Đây là phần cần kiểm thử kỹ trên tài khoản thử nghiệm trước khi chạy thật.

Nối vào MT5: lưu ý về hệ điều hành

MetaTrader 5 có thư viện Python chính thức, nhưng thư viện này cần terminal MT5 cài trên cùng máy và chỉ chạy trên Windows.

Nếu VPS của bạn là Windows, cách làm gọn nhất là cài terminal MT5 trên cùng VPS đó, đăng nhập tài khoản, bật cho phép thuật toán giao dịch, rồi server Python gọi trực tiếp thư viện để lấy giá, đặt lệnh và quản lý vị thế.

Nếu VPS của bạn là Linux, bạn có hai lựa chọn. Một là dùng một Windows VPS riêng chỉ để chạy phần MT5, và server Linux sẽ gọi sang đó qua một API nội bộ. Hai là dùng cầu nối qua file: server Linux ghi tín hiệu thành file, một Expert Advisor trên MT5 đọc file và đặt lệnh. Cách thứ hai chậm hơn nhưng ổn định và dễ kiểm soát, đặc biệt khi bạn chỉ giao dịch vài tín hiệu mỗi ngày.

Một chi tiết thực tế với MT5 là tên cặp có thể có hậu tố tuỳ broker, ví dụ XAUUSD.a. Hãy để phần này trong cấu hình thay vì gõ cứng trong payload, và kiểm tra tên cặp bằng cách đọc danh sách ký hiệu từ terminal một lần.

Quản lý cấu hình và khoá API

Nguyên tắc duy nhất cần nhớ: không có khoá nào nằm trong mã nguồn.

Mọi khoá cần đọc từ biến môi trường hoặc từ một tệp cấu hình nằm ngoài kho mã nguồn, và tệp đó phải được liệt kê trong danh sách bỏ qua của Git. Nếu bạn từng commit một khoá, hãy coi như khoá đó đã bị lộ và thay ngay, vì lịch sử commit vẫn lưu lại nó.

Cấu hình tối thiểu cần có gồm: khoá bí mật cho webhook, API key và secret của sàn, cờ chạy thật hay chạy demo, giới hạn khối lượng tối đa mỗi lệnh, số lệnh mở tối đa, và hệ số quy đổi khối lượng.

Hai cấu hình cuối rất quan trọng với người mới. Giới hạn khối lượng tối đa là lá chắn cuối cùng nếu logic của bạn tính sai khối lượng. Số lệnh mở tối đa là lá chắn nếu cơ chế chống trùng thất bại.

Ghi log đúng cách

Log là thứ duy nhất giúp bạn trả lời câu hỏi vì sao có lệnh đó, nên hãy ghi đủ ngay từ đầu.

Bốn nhóm thông tin nên có trong mỗi lần xử lý: thời điểm nhận, nội dung thô của payload, quyết định của bot, và phản hồi của sàn. Ngoài ra nên lưu mã lệnh mà sàn trả về, vì đó là cách bạn đối chiếu với lịch sử giao dịch.

Hai chi tiết vận hành dễ bị bỏ qua. Một là ghi log ra file với chế độ xoay vòng để file không phình vô hạn. Hai là ghi log theo định dạng có cấu trúc, ví dụ mỗi dòng một JSON, để sau này bạn lọc và thống kê dễ dàng hơn nhiều so với log văn bản tự do.

Điều cần tránh là ghi cả khoá bí mật và API key vào log. Đây là lỗi rất phổ biến khi người mới in toàn bộ đối tượng cấu hình ra để gỡ lỗi.

Chạy trên VPS với HTTPS

Ở chế độ phát triển, bạn chạy server bằng lệnh Python trực tiếp. Ở chế độ sản xuất, cần ba thứ.

Thứ nhất là máy chủ ứng dụng chạy ở chế độ sản xuất thay vì máy chủ phát triển. Thứ hai là một lớp proxy đứng trước để xử lý HTTPS và chuyển tiếp request vào ứng dụng. Thứ ba là một dịch vụ quản lý tiến trình để ứng dụng tự khởi động lại khi máy khởi động lại hoặc khi ứng dụng gặp sự cố.

Ngoài ra, dịch vụ quản lý tiến trình nên được cấu hình để tự chạy lại khi lỗi, và tường lửa chỉ nên mở cổng HTTPS ra ngoài, các cổng khác chỉ mở cho địa chỉ của bạn.

Giám sát và nhịp tim

Bot chạy tốt nhưng không nhận được tín hiệu là tình huống nguy hiểm hơn bot báo lỗi, vì nó im lặng.

Có ba lớp giám sát nên có. Thứ nhất là nhịp tim: một alert riêng bắn định kỳ, ví dụ mỗi ngày một lần, và server ghi lại. Nếu quá hai ngày không thấy nhịp tim, bạn biết có gì đó đã đứt, có thể là alert hết hạn hoặc gói TradingView hết hạn.

Thứ hai là cảnh báo lỗi qua một kênh bạn hay dùng, ví dụ tin nhắn tới Telegram. Những lỗi nên báo ngay gồm: lệnh bị sàn từ chối, không đọc được payload, và phát hiện tín hiệu trùng.

Thứ ba là báo cáo cuối ngày: số tín hiệu nhận được, số lệnh đặt thành công, số lệnh lỗi, và danh sách vị thế đang mở. Một tin nhắn ngắn mỗi ngày giúp bạn phát hiện những bất thường mà log không thể hiện rõ.

Ba lỗi hay gặp khi triển khai

Lỗi thứ nhất là endpoint không truy cập được từ internet. Dấu hiệu là alert tạo được nhưng log không có gì. Nguyên nhân thường là tường lửa chặn cổng, ứng dụng chỉ lắng nghe trên địa chỉ nội bộ, hoặc proxy chưa chuyển tiếp đúng đường dẫn.

Lỗi thứ hai là lệch múi giờ. Dấu hiệu là tín hiệu được ghi nhận lệch vài giờ so với thời điểm trên chart, và các so sánh theo thời gian bị sai. Nguyên nhân là lẫn lộn giữa thời gian máy chủ, thời gian nến từ TradingView và múi giờ sàn.

Lỗi thứ ba là bot mất kiểm soát khối lượng. Dấu hiệu là lệnh có khối lượng lớn hơn nhiều lần dự kiến trong thị trường biến động mạnh. Nguyên nhân là khối lượng được tính theo số dư nhưng không có giới hạn trần, và không có bước làm tròn theo bước khối lượng của sàn.

Checklist trước khi cho server chạy tiền thật

• Endpoint chạy sau HTTPS với chứng chỉ hợp lệ, đã kiểm tra từ bên ngoài.
• Có xác thực khoá bí mật và từ chối mọi payload sai khoá.
• Có chống trùng theo mã tín hiệu với thời gian sống cấu hình được.
• Luôn trả về 200 nhanh, việc gọi API sàn nằm ở luồng riêng.
• Khối lượng được làm tròn đúng theo bước của sàn và có giới hạn trần.
• Có giới hạn số lệnh mở tối đa trên mỗi mã.
• Mọi khoá API đọc từ biến môi trường, không có khoá trong mã nguồn.
• API key chỉ có quyền giao dịch, không có quyền rút tiền.
• Log có đủ bốn nhóm thông tin và không chứa khoá.
• Có nhịp tim và cảnh báo lỗi qua kênh bạn thường dùng.
• Đã chạy demo liên tục ít nhất vài tuần và có số liệu đối chiếu.
• Đã có cách tắt khẩn cấp và cách đóng toàn bộ vị thế bằng một lệnh.

Cấu trúc thư mục gợi ý cho dự án

Một dự án bot chạy được lâu dài thường có cấu trúc rõ ràng ngay từ đầu, vì bạn sẽ phải quay lại sửa nó nhiều lần.

Cách chia gọn gồm năm phần: phần cấu hình đọc biến môi trường, phần nhận webhook, phần thực thi giao dịch theo sàn, phần ghi log, và tệp chạy chính. Khi cần thêm một sàn mới, bạn chỉ thêm một tệp trong phần thực thi, không đụng tới phần nhận webhook.

Ba lợi ích cụ thể của cách chia này. Thứ nhất, bạn có thể thay đổi logic tín hiệu mà không sợ ảnh hưởng tới phần bảo mật. Thứ hai, bạn có thể viết kiểm thử cho phần thực thi mà không cần dựng cả server. Thứ ba, khi có lỗi, phạm vi tìm kiếm bị thu hẹp vào một tệp.

Điều nên tránh là để tất cả trong một tệp duy nhất dài hàng nghìn dòng. Cách này nhanh lúc bắt đầu nhưng sẽ làm bạn mất kiểm soát khi thêm sàn thứ hai hoặc thứ ba.

Kiểm thử cục bộ trước khi lên VPS

Một nguyên tắc tiết kiệm thời gian: mọi thứ nên chạy được trên máy bạn trước khi lên VPS. Việc gỡ lỗi qua VPS tốn thời gian gấp nhiều lần vì bạn phải chờ triển khai lại mỗi lần sửa.

Cách kiểm thử cục bộ hiệu quả nhất là tách việc gọi API sàn thành một chế độ mô phỏng. Ở chế độ này, thay vì gọi sàn, chương trình chỉ ghi ra thông tin lệnh sẽ được đặt: mã cặp, hướng, khối lượng, giá tham chiếu. Bạn cho hàng trăm payload chạy qua chế độ mô phỏng và đọc kết quả.

Ba thứ cần kiểm tra ở chế độ mô phỏng. Một là khối lượng có hợp lý không, đặc biệt với số dư nhỏ. Hai là các trường hợp biên như mã cặp lạ, khoá bí mật sai, JSON thiếu trường. Ba là tính chống trùng, bằng cách gửi cùng một payload hai lần và xác nhận chỉ có một lệnh được tính.

Sau khi phần mô phỏng đã sạch, bạn mới chuyển sang gọi API thật trên tài khoản demo. Lúc này lỗi còn lại chỉ thuộc về phía sàn, và bạn gỡ nhanh hơn nhiều.

Xử lý lỗi từ API sàn

Bỏ qua lỗi từ sàn là nguyên nhân phổ biến khiến bot âm thầm thất bại. Có bốn nhóm lỗi cần xử lý riêng.

Nhóm thứ nhất là lỗi khối lượng. Sàn từ chối khi khối lượng nhỏ hơn mức tối thiểu, lớn hơn mức tối đa, hoặc không đúng bước khối lượng. Cách xử lý là đọc thông tin thị trường từ sàn, làm tròn theo bước, và nếu khối lượng sau khi làm tròn bằng không thì không đặt lệnh mà ghi log cảnh báo.

Nhóm thứ hai là lỗi số dư hoặc ký quỹ. Cách xử lý là kiểm tra số dư khả dụng trước khi đặt lệnh, và định nghĩa rõ hành vi khi không đủ tiền: bỏ qua lệnh hay giảm khối lượng theo số dư còn lại. Hành vi này phải được quyết định trước, không phải tự phát sinh trong code.

Nhóm thứ ba là lỗi tần suất gọi API. Khi bạn gửi quá nhiều request trong thời gian ngắn, sàn có thể tạm khoá. Cách xử lý là chờ và thử lại với khoảng chờ tăng dần, đồng thời hạn chế gọi những API không cần thiết trong mỗi lần xử lý.

Nhóm thứ tư là lỗi mạng và lỗi tạm thời. Những lỗi này nên được thử lại, nhưng phải có giới hạn số lần, vì nếu thử lại vô hạn trong khi lệnh đã được đặt, bạn sẽ tạo lệnh trùng.

Một nguyên tắc chung: mọi nhánh xử lý lỗi đều phải ghi log, và những lỗi nghiêm trọng phải gửi cảnh báo tới kênh bạn thường dùng. Không được để bất kỳ lỗi nào bị nuốt trong im lặng.

Đồng bộ trạng thái khi khởi động lại

Bot của bạn sẽ khởi động lại, có thể do bạn triển khai phiên bản mới, do máy chủ khởi động lại, hoặc do tiến trình gặp sự cố. Điều gì xảy ra với các vị thế đang mở là câu hỏi phải được trả lời trước khi chạy tiền thật.

Cách tiếp cận an toàn nhất là coi sàn là nguồn sự thật duy nhất. Khi khởi động, bot đọc danh sách vị thế đang mở từ sàn, lưu vào trạng thái nội bộ, rồi mới bắt đầu nhận tín hiệu mới. Nhờ vậy, dù bot có quên gì đi nữa thì nó luôn bắt đầu từ thực tế.

Cách thứ hai là lưu trạng thái ra đĩa và đọc lại khi khởi động. Cách này nhanh hơn nhưng có rủi ro: nếu trạng thái đã lưu lệch với thực tế ở sàn, bot sẽ làm việc trên dữ liệu sai. Vì vậy nên dùng cách này kèm bước đối chiếu với sàn.

Một chi tiết quan trọng là trạng thái chống trùng cũng nên được lưu lại. Nếu bot khởi động lại và quên các mã tín hiệu đã xử lý, nó có thể mở lại lệnh cho một tín hiệu vừa mới nhận trước khi khởi động lại. Đây là kịch bản ít gặp nhưng hậu quả lớn, nên nếu bạn chạy nhiều chiến lược, hãy lưu mã tín hiệu vào Redis hoặc cơ sở dữ liệu.

Ước lượng tài nguyên cho VPS

Bot nhận webhook rất nhẹ, không cần cấu hình mạnh. Điều quan trọng hơn là sự ổn định của đường mạng và vị trí địa lý của máy chủ.

Tài nguyên cần thiết thường gồm: một lõi xử lý là đủ cho bot một chiến lược, bộ nhớ vài trăm megabyte là thoải mái, và dung lượng đĩa chỉ cần đủ cho log trong vài tháng. Nếu bạn chạy thêm phần MT5 trên Windows thì yêu cầu cao hơn hẳn vì terminal MT5 cần thêm tài nguyên.

Yếu tố quan trọng hơn cấu hình là vị trí máy chủ. Chọn máy chủ gần sàn hoặc gần trung tâm dữ liệu mà sàn sử dụng để giảm độ trễ. Với bot giao dịch khung phút trở lên, sự khác biệt này nhỏ; với chiến lược tần suất cao thì lại rất đáng kể.

Cuối cùng, hãy chọn nhà cung cấp có cơ chế khởi động lại dịch vụ ổn định và có cách mở console dự phòng khi mạng chính gặp vấn đề. Một máy chủ nhanh nhưng bạn không vào được lúc cần sẽ vô dụng đúng vào thời điểm quan trọng nhất.

Kết luận

Server nhận webhook TradingView bằng Python không cần nhiều code, nhưng cần đúng ở bốn điểm: xác thực bằng khoá bí mật, chống trùng bằng mã tín hiệu, phản hồi nhanh và xử lý lệnh ở luồng riêng, và ghi log đủ để tra cứu. Khi bốn điểm này đã ổn, phần nối thêm sàn mới chỉ là thêm một module.

Nếu bạn muốn viết được server này cho cả MT5, Binance và chứng khoán Việt Nam, có người sửa lỗi trực tiếp trong buổi học, hãy xem Bootcamp TradingView Webhook Bot của Hướng Nghiệp AI. Khoá học gồm sáu buổi online qua Zoom, có bản ghi từng buổi và tặng một buổi 1-1 để rà lại hệ thống của bạn.

Đọc tiếp trong chuỗi: TradingView Webhook Bot là gì, cách tạo alert TradingView gửi webhook, mẫu JSON cho Pine Script alert và bảo mật webhook TradingView.