Mục lục · 8 phần
- Webhook bắt đầu từ một sự kiện đã xảy ra
- Một đơn hàng đi qua webhook như thế nào?
- Dùng webhook để bớt việc lặp lại trong shop
- Ví dụ tính thời gian được tiết kiệm, không tự gán doanh thu
- Tự làm endpoint: phần nào AI có thể hỗ trợ?
- Khi nào nên dùng API thay vì webhook?
- Những lỗi khiến dữ liệu tự động bị rối
- Câu hỏi thường gặp
Trả lời nhanh
Webhook là địa chỉ nhận tin tự động giữa hai phần mềm khi một sự kiện đã xảy ra, như có đơn hàng mới. Nó chờ hệ thống gửi thông báo, không tự đi tìm dữ liệu. Anh/chị cần có endpoint nhận gói dữ liệu để ứng dụng đọc thông tin rồi thực hiện việc tiếp theo đã cài đặt.
Webhook là địa chỉ nhận tin tự động giữa hai phần mềm. Khi một việc đã xảy ra, như có đơn mới hoặc khách vừa điền form, hệ thống gửi tin tới địa chỉ đó ngay; anh/chị không phải liên tục vào từng nơi để kiểm tra.
Webhook bắt đầu từ một sự kiện đã xảy ra
Webhook không tự đi tìm dữ liệu. Nó chờ một sự kiện ở hệ thống gửi. Sự kiện là việc cụ thể mà máy nhận ra được, chẳng hạn khách thanh toán thành công, đơn đổi sang trạng thái mới, hoặc khách vừa để lại số điện thoại.
Khi sự kiện xảy ra, bên gửi tạo một gói dữ liệu rồi gửi tới một đường dẫn trên internet. Đường dẫn này gọi là endpoint, tức nơi ứng dụng của anh/chị mở sẵn để nhận tin. Bên nhận đọc gói đó rồi làm việc tiếp theo đã được cài đặt.
Hình dung quầy đóng gói có một chuông cửa. Mỗi khi có đơn phù hợp, chuông reo và kèm tờ giấy ghi thông tin cần xử lý. Webhook là cách để hệ thống bấm chuông. Nó không thay người đóng gói, không tự tạo đơn và cũng không sửa được dữ liệu sai từ nguồn gửi.
Điều cần nhớ là webhook chỉ báo về việc mới phát sinh sau khi anh/chị đã bật nó. Nếu hôm nay anh/chị kết nối một công cụ, công cụ đó thường không tự mang toàn bộ đơn của tháng trước sang. Muốn lấy dữ liệu cũ, anh/chị thường cần dùng API hoặc chức năng xuất dữ liệu riêng.
Một đơn hàng đi qua webhook như thế nào?
Một luồng đơn giản có bốn bước. Bước đầu, khách hoàn tất một hành động trên nền tảng bán hàng. Bước hai, nền tảng kiểm tra xem sự kiện đó có webhook nào đã đăng ký hay không. Bước ba, nền tảng gửi dữ liệu đến endpoint của anh/chị. Bước cuối, endpoint trả lời đã nhận được và xử lý theo quy tắc của shop.
Ví dụ, anh/chị có một form nhận đăng ký tư vấn. Lúc 09:15, một khách để lại số điện thoại. Form có thể gửi webhook sang CRM, tức phần mềm lưu và theo dõi khách hàng. CRM tạo một khách mới, gắn nhãn “cần gọi”, rồi báo cho nhân viên. Chuỗi này diễn ra vì có sự kiện “gửi form”, không phải vì nhân viên ngồi chép tay.
Webhook thường gửi dữ liệu theo dạng JSON, tức một khối chữ có cặp tên và giá trị để máy đọc. Một gói đơn hàng có thể gồm mã đơn, số tiền, tên sản phẩm và trạng thái thanh toán. Anh/chị không cần thuộc cú pháp JSON để hiểu quy trình, nhưng cần biết phải xác định rõ trường nào sẽ được dùng trước khi nhờ AI viết công cụ.
Chẳng hạn công cụ chỉ cần tên khách và số điện thoại để tạo việc gọi lại. Nếu nó nhận cả địa chỉ giao hàng, anh/chị không nên tự động đẩy địa chỉ vào nhóm chat chung. Webhook giúp dữ liệu chạy nhanh hơn, nên việc chọn đúng dữ liệu cũng quan trọng hơn.
Dùng webhook để bớt việc lặp lại trong shop
Trường hợp dễ thấy nhất là nhận lead, tức thông tin người có khả năng mua hàng. Khách điền form quảng cáo lúc 14:20. Webhook có thể gửi tên và số điện thoại về CRM ngay lúc đó. Nhân viên không cần mở quảng cáo, tải bảng dữ liệu rồi mới phân cho người gọi.
Trường hợp thứ hai là cập nhật thanh toán. Khi cổng thanh toán báo giao dịch đã thành công, webhook có thể đổi trạng thái đơn từ “chờ thanh toán” sang “có thể xử lý”. Quy tắc này chỉ nên chạy nếu bên gửi xác nhận giao dịch hợp lệ. Đừng dùng một tin nhắn khách tự gửi làm điều kiện tự động xuất hàng.
Trường hợp thứ ba là báo lỗi cho người phụ trách. Ví dụ, nếu công cụ đồng bộ nhận một đơn nhưng thiếu số điện thoại, nó có thể gửi thông báo vào kênh nội bộ để kiểm tra. Đây là thông báo về một tình huống cần xử lý, không phải bằng chứng rằng đơn đó đã bị hủy.
Một shop có doanh số trên 100 triệu mỗi ngày có thể có nhiều luồng như vậy cùng lúc: đơn hàng, tồn kho, quảng cáo và chăm sóc khách. Webhook không làm doanh số tự tăng. Giá trị của nó là giảm khoảng trống giữa lúc dữ liệu phát sinh và lúc đúng người nhìn thấy dữ liệu.
Ví dụ tính thời gian được tiết kiệm, không tự gán doanh thu
Webhook không có một công thức lợi nhuận cố định. Anh/chị có thể tính phần việc thủ công được cắt bớt để quyết định có đáng làm hay không.
Ví dụ, mỗi lần nhân viên chép một khách từ form vào CRM mất 2 phút. Trong một ngày có 30 khách. Tổng thời gian chép là 2 phút × 30 khách = 60 phút mỗi ngày. Nếu webhook tạo khách tự động, phần 60 phút này có thể được chuyển sang việc gọi, kiểm tra thông tin hoặc xử lý khách cần hỗ trợ.
Con số 60 phút không có nghĩa shop chắc chắn bán thêm được bao nhiêu tiền. Nó chỉ là thời gian thao tác được tính từ giả định 2 phút cho mỗi khách và 30 khách trong ngày. Nếu form của anh/chị chỉ có 3 khách một ngày, phép tính là 2 phút × 3 khách = 6 phút; khi đó có thể chưa cần xây một luồng phức tạp.
Ví dụ khác là kiểm tra đơn. Nếu một người mất 3 phút để kiểm tra một trạng thái thanh toán và cần làm 20 lần, thời gian là 3 phút × 20 lần = 60 phút. Webhook có thể báo ngay khi trạng thái thay đổi, nhưng shop vẫn phải định rõ đơn nào được tự động chuyển bước và đơn nào cần người duyệt.
Đừng lấy số liệu quảng cáo làm bằng chứng trực tiếp cho webhook. Chẳng hạn ROAS 8,54 — CPAS Facebook về Shopee, 16-20/8/2026 — chỉ nói doanh thu được quy cho quảng cáo cao gấp 8,54 lần chi phí quảng cáo trong báo cáo đó. Nó không chứng minh webhook tạo ra ROAS này. Webhook và quảng cáo có thể cùng nằm trong một quy trình, nhưng là hai việc khác nhau.
Số liệu thực tế từ tài khoản đang vận hành, ghi nhận tại thời điểm nêu trên. Kết quả từng shop khác nhau tuỳ ngành hàng, giá bán và ngân sách.
Tự làm endpoint: phần nào AI có thể hỗ trợ?
Khi tự viết mã ứng dụng phục vụ công việc marketing, anh/chị có thể nhờ AI tạo khung endpoint. Nhưng trước khi viết mã, hãy ghi cho rõ ba điều: webhook đến từ đâu, dữ liệu nào được phép lưu và sau khi nhận thì hệ thống làm gì.
Một endpoint tối thiểu thường nhận yêu cầu POST, tức một yêu cầu gửi dữ liệu tới, kiểm tra dữ liệu rồi trả phản hồi thành công. Ví dụ minh hoạ dưới đây chỉ cho thấy cấu trúc; hàm lưu dữ liệu phải được thay bằng nơi lưu của anh/chị.
“python @app.route('/nhan-don-hang', methods=['POST']) def nhan_don(): du_lieu = request.json luu_vao_bang_tinh(du_lieu) return 'Đã nhận', 200 “
Mã 200 nghĩa là máy chủ đã nhận yêu cầu thành công. Nó không tự nói rằng mọi bước phía sau đã hoàn tất đúng. Nếu luu_vao_bang_tinh() bị lỗi mà chương trình vẫn trả 200, bên gửi có thể nghĩ mọi thứ ổn trong khi dữ liệu chưa được lưu. Vì vậy, phản hồi thành công chỉ nên gửi sau các kiểm tra quan trọng.
Nhiều nền tảng gửi kèm chữ ký để xác minh webhook. Chữ ký là một giá trị dùng để kiểm tra gói tin có đúng từ bên gửi hay không và có bị thay đổi trên đường đi hay không. Anh/chị cần đọc tài liệu của chính nền tảng đang kết nối để biết họ dùng chữ ký nào, gửi ở đâu và phải kiểm tra ra sao. Đừng bỏ qua bước này chỉ vì endpoint đang hoạt động trong lúc thử nghiệm.
Mỗi sự kiện nên có mã riêng để tránh xử lý trùng. Ví dụ bên gửi thử lại cùng một tin vì lần trước mạng chập chờn. Nếu công cụ của anh/chị tạo thêm một dòng mới mỗi lần nhận được, một đơn có thể thành hai dòng. Hãy lưu mã sự kiện hoặc mã đơn đã xử lý, rồi kiểm tra trước khi tạo bản ghi mới.
Để giữ mã nguồn có lịch sử thay đổi và dễ nhờ AI rà soát, anh/chị nên làm quen với Git/GitHub. Việc này đặc biệt hữu ích khi một chỉnh sửa nhỏ ở endpoint có thể ảnh hưởng tới dữ liệu nhận mỗi ngày.
Tài liệu về webhook của GitHub giải thích rõ cách sự kiện được gửi tới một payload URL và cách nhận biết lần giao hàng thành công hay thất bại. Đây là một ví dụ kỹ thuật gốc để anh/chị đối chiếu khi xây endpoint, dù hệ thống của anh/chị có thể dùng nền tảng khác: GitHub Docs: About webhooks.
Khi nào nên dùng API thay vì webhook?
API là cách ứng dụng của anh/chị chủ động hỏi hệ thống khác để lấy hoặc gửi dữ liệu. Webhook là cách hệ thống kia chủ động báo cho anh/chị khi có sự kiện. Hai cách thường được dùng cùng nhau.
Ví dụ, anh/chị muốn kéo 100 đơn cũ để đối soát. Đây là việc hỏi lấy dữ liệu có sẵn, nên API phù hợp hơn. Nếu anh/chị muốn nhận tin ngay khi đơn thứ 101 vừa phát sinh, webhook phù hợp hơn. Con số 100 và 101 chỉ để phân biệt dữ liệu lịch sử với sự kiện mới, không phải giới hạn kỹ thuật.
Một cách làm an toàn là dùng webhook để nhận tin nhanh, rồi dùng API để lấy lại chi tiết khi cần. Ví dụ webhook chỉ gửi mã đơn. Công cụ nhận mã đơn, sau đó gọi API để lấy thông tin cần thiết. Cách này hữu ích khi gói webhook không chứa đủ dữ liệu hoặc khi anh/chị muốn luôn lấy bản dữ liệu mới nhất từ nguồn.
Không phải việc gì cũng cần thời gian thực. Báo cáo doanh thu cuối ngày có thể chạy lúc cố định. Nếu một bảng chỉ cần cập nhật 1 lần mỗi ngày, việc lấy dữ liệu theo lịch có thể dễ quản lý hơn endpoint luôn mở. Hãy chọn webhook khi việc chậm vài phút gây ảnh hưởng rõ tới vận hành, như bỏ lỡ lead hoặc để đơn đã thanh toán nằm chờ.
Những lỗi khiến dữ liệu tự động bị rối
Lỗi đầu tiên là dùng một đường dẫn công khai nhưng không kiểm tra chữ ký. Khi đó, bất kỳ ai biết địa chỉ có thể thử gửi dữ liệu giả. Endpoint cần kiểm tra trước khi tạo đơn, thêm khách hoặc gửi thông báo.
Lỗi thứ hai là xử lý quá nhiều việc trong một lần nhận. Ví dụ webhook nhận đơn rồi ngay lập tức tạo hóa đơn, trừ tồn kho, gửi ba tin nhắn và tạo báo cáo. Nếu một bước chậm, bên gửi có thể hết thời gian chờ. Hãy nhận tin nhanh, lưu nó an toàn, rồi để phần việc nặng chạy sau.
Lỗi thứ ba là không chuẩn bị cho dữ liệu thiếu. Một khách có thể không cung cấp số điện thoại, một sản phẩm có thể thiếu mã nội bộ, hoặc trạng thái đơn có thể chưa đúng như anh/chị dự kiến. Thay vì để chương trình dừng, hãy đưa bản ghi đó vào danh sách cần kiểm tra.
Lỗi cuối là không lưu nhật ký. Nhật ký là dấu vết ghi lại webhook nào đã đến, lúc nào đến và chương trình đã trả lời gì. Khi nhân viên hỏi vì sao một đơn không xuất hiện, nhật ký giúp phân biệt ba khả năng: bên gửi chưa gửi, endpoint không nhận được, hoặc endpoint nhận rồi nhưng xử lý lỗi.
Câu hỏi thường gặp
Webhook có phải là API không?
Webhook và API đều giúp phần mềm trao đổi dữ liệu, nhưng cách khởi động khác nhau. Với API, công cụ của anh/chị chủ động hỏi. Với webhook, hệ thống nguồn chủ động gửi tin khi có sự kiện.
Làm sao biết webhook đã chạy hay chưa?
Anh/chị hãy tạo một sự kiện thử, như gửi một form thử hoặc đổi trạng thái một đơn thử, rồi xem nhật ký ở bên gửi và bên nhận. Cần kiểm tra cả nội dung dữ liệu lẫn mã phản hồi; nhận mã 200 cho biết yêu cầu đã được máy chủ chấp nhận.
Webhook bị gửi hai lần thì đơn có bị tạo trùng không?
Có thể bị trùng nếu công cụ không kiểm tra mã sự kiện hoặc mã đơn trước khi tạo dữ liệu mới. Hãy lưu mã đã xử lý và bỏ qua lần gửi lại có cùng mã. Đây là bước cần có trước khi áp dụng tự động cho đơn thật.
Tôi có cần thuê lập trình viên để dùng webhook không?
Không nhất thiết, nếu công cụ anh/chị dùng đã có sẵn phần kết nối hoặc trình tạo tự động hoá. Khi cần endpoint riêng, anh/chị vẫn nên nhờ người có kinh nghiệm kiểm tra bảo mật, dữ liệu nhạy cảm và cách xử lý lỗi trước khi bật cho toàn bộ đơn.
Webhook có lấy được toàn bộ đơn hàng cũ không?
Thông thường webhook báo sự kiện mới từ sau lúc được bật, không phải công cụ tải lại lịch sử. Để lấy đơn cũ, anh/chị cần xem API hoặc chức năng xuất dữ liệu mà nền tảng đó cung cấp.
Nếu endpoint bị lỗi lúc có đơn mới thì sao?
Bên gửi có thể thử gửi lại, nhưng cách thử lại khác nhau theo từng nền tảng. Anh/chị không nên đoán số lần hay thời gian gửi lại; hãy kiểm tra tài liệu của nền tảng đang dùng và theo dõi nhật ký endpoint để biết tin nào cần xử lý lại.
