Webhook là cách một ứng dụng tự báo cho ứng dụng khác ngay khi có chuyện xảy ra, thay vì để bên kia phải hỏi đi hỏi lại. Có đơn hàng mới, có người gửi biểu mẫu, có thanh toán thành công: ứng dụng nguồn gửi ngay một gói tin ngắn tới một địa chỉ bạn đã đăng ký trước. Nó giống chuông cửa, khách bấm là trong nhà biết, không ai phải ra cửa ngó mỗi năm phút.
Bài này giải thích webhook bằng ngôn ngữ thường ngày, so sánh với cách gọi API hỏi định kỳ, chỉ ra lúc nào dùng cái nào, và nêu những chuyện hay gặp như báo trùng, báo trễ, báo mất mà người mới tự động hoá thường không lường trước.
Hai cách biết có đơn hàng mới: ra cửa ngó và nghe chuông
Giả sử bạn muốn mỗi đơn hàng mới trên cửa hàng online tự hiện vào bảng theo dõi của tổ đóng gói. Có hai cách để bảng theo dõi biết là có đơn mới.
Cách thứ nhất là hỏi định kỳ, tiếng Anh gọi là polling. Cứ mười lăm phút, luồng tự động gọi API của cửa hàng một lần: có đơn nào mới từ lần hỏi trước không. Phần lớn lần hỏi nhận về câu trả lời không có gì. Cách này đơn giản, ứng dụng nào có API đọc dữ liệu là làm được, nhưng chậm tối đa bằng khoảng cách giữa hai lần hỏi, và tốn lượt gọi cho những lần hỏi vô ích.
Cách thứ hai là webhook. Bạn vào phần cài đặt của cửa hàng, đăng ký một địa chỉ nhận và chọn sự kiện đơn hàng được tạo. Từ đó mỗi lần có đơn, cửa hàng tự gửi thông tin đơn tới địa chỉ ấy trong vài giây. Không có đơn thì không có gói tin nào. Đây là lý do webhook được gọi vui là API ngược: thay vì bạn gọi tới họ, họ gọi tới bạn.
Trong công cụ kết nối kéo thả, nhiều ô kích hoạt như khi có đơn hàng mới thực chất chạy bằng một trong hai cách trên. Biết ô đó đang dùng cách nào giúp bạn hiểu vì sao có luồng chạy tức thì, có luồng trễ vài phút.
So sánh hỏi định kỳ và webhook
Không cách nào luôn hơn cách nào. Bảng sau giúp bạn chọn theo đúng việc.
| Tiêu chí | Hỏi định kỳ qua API | Webhook |
|---|---|---|
| Độ trễ | Bằng khoảng cách giữa hai lần hỏi, từ vài phút tới vài giờ | Thường vài giây sau sự kiện |
| Lượt gọi tiêu tốn | Tốn đều đặn kể cả khi không có gì mới | Chỉ khi có sự kiện |
| Điều kiện | Ứng dụng nguồn có API đọc dữ liệu | Ứng dụng nguồn hỗ trợ gửi webhook cho đúng sự kiện bạn cần |
| Nguy cơ hay gặp | Bỏ sót nếu cách đánh dấu lần hỏi trước bị sai, lấy trùng khi đổi giờ | Mất gói tin khi bên nhận đang lỗi, nhận trùng khi bên gửi gửi lại |
| Phù hợp | Báo cáo theo ngày, đồng bộ không gấp, ứng dụng không có webhook | Đơn hàng, đặt lịch, thanh toán, tin nhắn khách cần phản hồi nhanh |
Nhiều luồng chắc chắn dùng cả hai: webhook để phản ứng nhanh, cộng một lần hỏi định kỳ mỗi đêm để vét những đơn mà webhook lỡ bỏ sót. Cách kết hợp này rẻ và giúp bạn ngủ yên hơn.
Một gói webhook gồm những gì
Địa chỉ nhận. Là đường dẫn bắt đầu bằng https do công cụ kết nối hoặc máy chủ của bạn cấp. Ai biết địa chỉ này đều có thể gửi gói tin tới, nên coi nó như một thứ nửa bí mật, không dán lên nhóm chat chung.
Tên sự kiện. Cho biết chuyện gì vừa xảy ra, ví dụ đơn được tạo, đơn bị huỷ, khách cập nhật địa chỉ. Một địa chỉ nhận có thể nhận nhiều loại sự kiện, luồng phải đọc tên sự kiện để rẽ nhánh cho đúng.
Nội dung dữ liệu. Thường là một khối JSON chứa thông tin của đối tượng: mã đơn, danh sách sản phẩm, tổng tiền, thông tin người nhận. Có nơi gửi đầy đủ, có nơi chỉ gửi mã rồi để bạn tự gọi API lấy chi tiết.
Chữ ký hoặc mã xác minh. Nhiều ứng dụng đính kèm một chuỗi ký bằng mã bí mật chung giữa hai bên, để bên nhận kiểm gói tin có đúng do họ gửi không. Công cụ kéo thả nhiều loại tự kiểm phần này nếu bạn dán mã bí mật vào ô cài đặt.
Thời điểm và mã định danh của lần gửi. Giúp phát hiện gói tin gửi trùng hoặc gói tin cũ bị gửi lại. Đây là chi tiết nhỏ nhưng rất quan trọng khi luồng ghi đơn vào bảng hay gửi email cho khách.
Ba chuyện người mới hay gặp: báo trùng, báo trễ, báo mất
Bên gửi webhook thường chờ bên nhận trả lời đã nhận trong vài giây. Nếu không nhận được câu trả lời thành công, họ cho là gửi hỏng và gửi lại sau một lúc, có nơi thử lại nhiều lần trong một đến vài ngày. Hệ quả là cùng một đơn có thể tới hai lần, nhất là khi luồng của bạn xử lý chậm, ví dụ có bước AI tóm tắt mất mười giây trước khi kịp báo đã nhận. Cách phòng là lưu mã đơn hoặc mã lần gửi đã xử lý, gặp lại thì bỏ qua.
Báo trễ xảy ra khi bên gửi đang quá tải, hoặc khi một lần gửi trước bị lỗi và đang trong vòng chờ gửi lại. Thứ tự gói tin cũng có thể đảo: sự kiện đơn được sửa tới trước sự kiện đơn được tạo. Luồng không nên giả định thứ tự; khi nhận sự kiện sửa mà chưa có đơn trong bảng, hãy tạo mới thay vì báo lỗi.
Báo mất là ca khó chịu nhất. Nếu địa chỉ nhận ngừng hoạt động quá lâu, chẳng hạn bạn tắt luồng để sửa, bên gửi có thể hết lượt thử lại và bỏ hẳn, thậm chí một số nơi tự vô hiệu hoá webhook sau nhiều lần thất bại liên tiếp. Bạn cần một cách phát hiện: so số đơn trong bảng với số đơn trong phần mềm bán hàng mỗi ngày, hoặc có lần quét vét ban đêm như đã nói ở trên.
Các bước đăng ký một webhook trong thực tế
Tên nút mỗi ứng dụng một khác và thay đổi theo phiên bản, nên các bước dưới đây viết theo nguyên lý. Đối chiếu với giao diện hiện hành của ứng dụng bạn dùng.
- Trong công cụ kết nối, tạo luồng mới với ô kích hoạt kiểu nhận webhook, công cụ sẽ cấp cho bạn một địa chỉ nhận riêng.
- Sao chép địa chỉ đó, mở phần cài đặt dành cho nhà phát triển hoặc phần thông báo của ứng dụng nguồn, tìm mục webhook và dán vào.
- Chọn đúng sự kiện cần nghe. Đừng chọn tất cả cho tiện, vì luồng sẽ chạy cho cả những sự kiện không liên quan và tốn lượt chạy.
- Nếu ứng dụng cấp mã bí mật để ký gói tin, lưu mã đó vào chỗ cất khoá của công cụ kết nối, không ghi trong ghi chú luồng.
- Bấm gửi thử, hoặc tạo một đơn hàng giả với tên khách giả định. Xem gói tin nhận được có đủ các trường bạn cần chưa.
- Dựng tiếp các bước phía sau, rồi thử lại toàn bộ bằng dữ liệu giả trước khi bật cho đơn thật.
Khi dựng xong, ghi lại ở một chỗ chung: webhook này đăng ký ở ứng dụng nào, bằng tài khoản ai, nghe sự kiện gì, gửi về luồng nào. Sáu tháng sau, khi người khác cần sửa, tờ ghi chú đó tiết kiệm cho họ cả buổi dò tìm.
Webhook có dữ liệu khách hàng: những điều phải nghĩ trước
Gói webhook của đơn hàng thường mang tên, số điện thoại, địa chỉ của khách. Gói tin đó đi qua công cụ kết nối, có thể được lưu trong lịch sử chạy của luồng nhiều ngày để bạn xem lại khi sửa lỗi. Hãy kiểm phần cài đặt lưu lịch sử của công cụ và rút ngắn thời gian lưu nếu không cần.
Nếu luồng có bước AI, chẳng hạn phân loại tin nhắn khách hay soạn nháp lời cảm ơn, chỉ chuyển cho bước AI đúng phần nó cần. Phân loại nội dung khiếu nại không cần số điện thoại của khách, soạn lời cảm ơn chỉ cần tên gọi và tên sản phẩm. Cắt bớt trường trước khi gửi đi là cách che dữ liệu đơn giản mà hiệu quả.
Cuối cùng, địa chỉ nhận webhook mà lọt ra ngoài thì ai cũng có thể gửi gói tin giả vào luồng của bạn, ví dụ tạo đơn ảo để lừa tổ đóng gói. Nếu ứng dụng nguồn có cơ chế ký, hãy bật kiểm chữ ký. Nếu không, đặt ít nhất một bước kiểm chéo: nhận mã đơn rồi gọi API ngược lại cửa hàng để xác nhận đơn có thật trước khi làm gì tiếp.
Khi nào webhook không phải lựa chọn đúng
Webhook mạnh nhưng không phải lúc nào cũng cần. Nếu bạn chỉ cần tổng doanh thu cuối ngày gửi vào nhóm chat lúc chín giờ tối, một lần gọi API theo lịch là gọn hơn hẳn so với nhận từng đơn qua webhook rồi tự cộng. Nếu ứng dụng nguồn chỉ hỗ trợ webhook ở gói trả phí cao, hỏi định kỳ mỗi giờ có khi đủ cho cửa hàng vài chục đơn một ngày.
Cũng có ca ứng dụng nguồn không gửi webhook cho đúng sự kiện bạn cần. Ví dụ ứng dụng có báo khi đơn được tạo nhưng không báo khi khách đổi địa chỉ. Lúc đó, kết hợp: webhook cho đơn mới, hỏi định kỳ cho thay đổi địa chỉ. Đừng cố bắt luồng phỏng đoán thay đổi từ dữ liệu không có.
Một ca nữa hay bị bỏ qua là khi chính bạn không kiểm soát được thời điểm luồng sẵn sàng. Ví dụ luồng nhận webhook chạy trên tài khoản dùng thử sắp hết hạn, hoặc trên tài khoản cá nhân của một nhân viên sắp nghỉ. Khi tài khoản đó ngừng, địa chỉ nhận chết theo, và ứng dụng nguồn cứ gửi vào khoảng không. Trước khi đăng ký webhook cho việc quan trọng, chuyển luồng về tài khoản của công ty, có ít nhất hai người biết mật khẩu quản trị.
Lời khuyên chung: thiết kế luồng từ câu hỏi chậm bao lâu thì vẫn chấp nhận được. Chậm năm phút không sao thì hỏi định kỳ là đủ và dễ gỡ lỗi hơn. Chậm một phút đã mất khách thì mới cần webhook cùng các lớp phòng trùng, phòng mất đi kèm.
Câu hỏi thường gặp
Webhook có cần máy chủ riêng không?
Với người không lập trình thì không. Các công cụ kết nối kéo thả cấp sẵn địa chỉ nhận webhook cho từng luồng. Chỉ khi cần xử lý khối lượng rất lớn hoặc logic phức tạp mới phải dựng máy chủ riêng, lúc đó nên nhờ lập trình viên.
Vì sao đã bấm gửi thử mà luồng không nhận được gì?
Thường do dán sai địa chỉ nhận, luồng đang tắt, hoặc chọn sai sự kiện. Kiểm lại địa chỉ đầy đủ, bật chế độ chờ nhận thử trong công cụ kết nối nếu có, rồi gửi lại. Xem thêm nhật ký gửi ở phía ứng dụng nguồn để biết họ nhận được mã phản hồi nào.
Nhận trùng đơn qua webhook thì xử lý ra sao?
Thêm một bước kiểm đầu luồng: tra mã đơn trong bảng theo dõi, đã có thì dừng. Đây là cách đơn giản nhất để luồng chịu được việc bên gửi gửi lại, vốn là hành vi bình thường chứ không phải lỗi.
Địa chỉ webhook bị lộ thì phải làm gì?
Tạo địa chỉ nhận mới trong công cụ kết nối, cập nhật sang ứng dụng nguồn, rồi xoá hoặc vô hiệu hoá địa chỉ cũ. Đồng thời rà lại dữ liệu nhận được trong khoảng thời gian nghi ngờ xem có gói tin lạ không.
Webhook có an toàn để truyền dữ liệu khách hàng không?
Đủ an toàn khi dùng địa chỉ https, bật kiểm chữ ký nếu có, không để lộ địa chỉ nhận, và giới hạn thời gian lưu lịch sử chạy. Chỉ chuyển cho các bước sau, nhất là bước AI, những trường thật sự cần.
Ứng dụng không có webhook thì còn cách nào?
Dùng hỏi định kỳ qua API nếu ứng dụng có API đọc dữ liệu. Nếu cả API cũng không có, còn cách nhận email thông báo của ứng dụng rồi để luồng đọc email đó, tuy kém tin cậy hơn vì mẫu email có thể đổi bất cứ lúc nào.