Kết nối API bằng webhook và HTTP request trong automation

Bạn tra thư viện kết nối của nền tảng automation đang dùng và không thấy tên phần mềm kế toán hay CRM trong nước mình đang dùng - đừng vội kết luận là "không tự động hoá được", vì hầu hết phần mềm hiện đại đều mở cổng API để phần mềm khác kết nối vào, chỉ là nền tảng automation không có sẵn giao diện kéo thả cho riêng nó. Bài viết này hướng dẫn từng bước dựng webhook nhận dữ liệu, gọi HTTP request có xác thực, đọc kết quả trả về và xử lý lỗi thường gặp, để bạn tự nối được bất kỳ phần mềm nào có API mà không cần chờ nền tảng automation hỗ trợ sẵn.

Webhook và HTTP request khác nhau ở đâu

Hai khái niệm này thường bị nhầm lẫn nhưng phục vụ hai chiều ngược nhau. Webhook là khi một phần mềm khác chủ động gửi dữ liệu tới luồng automation của bạn ngay khi có sự kiện xảy ra (ví dụ có đơn hàng mới) - luồng của bạn chỉ cần "ngồi chờ" ở một địa chỉ URL cố định. HTTP request (hay còn gọi là gọi API) là chiều ngược lại - luồng automation của bạn chủ động gửi yêu cầu tới một phần mềm khác để lấy dữ liệu hoặc yêu cầu thực hiện hành động (ví dụ lấy danh sách khách hàng, hoặc tạo một hoá đơn mới).

Hiểu đúng khác biệt này giúp bạn biết nên dùng cái nào trong từng tình huống: khi cần luồng phản ứng ngay lập tức với một sự kiện bên ngoài, dùng webhook; khi cần luồng chủ động lấy hoặc gửi dữ liệu theo lịch hoặc theo điều kiện, dùng HTTP request. Nhiều luồng automation thực tế dùng cả hai kết hợp - webhook để khởi động luồng, rồi HTTP request để lấy thêm dữ liệu hoặc thực hiện hành động tiếp theo.

Kỹ năng này áp dụng được trên hầu hết các nền tảng automation phổ biến, dù bạn dùng Zapier, Make hay n8n - node hoặc module "Webhook" và "HTTP Request" đều có mặt trên cả ba. Nếu bạn chưa chọn nền tảng nào, bài Nền tảng automation cho doanh nghiệp: bản đồ và cách chọn giúp bạn có bức tranh tổng quan trước khi đi vào kỹ thuật kết nối cụ thể trong bài này.

Bước 1: Dựng webhook để nhận dữ liệu

Hầu hết các nền tảng automation (Zapier, Make, n8n) đều có sẵn một khối (node/module) tên "Webhook" - khi thêm vào luồng, nền tảng sẽ tự tạo cho bạn một địa chỉ URL riêng biệt. Việc của bạn là dán địa chỉ URL này vào phần cấu hình "gửi thông báo tới" hoặc "callback URL" trong phần mềm nguồn (phần mềm bạn muốn lấy dữ liệu từ đó), nếu phần mềm đó hỗ trợ tính năng webhook. Không phải phần mềm nào cũng hỗ trợ gửi webhook - bạn cần kiểm tra tài liệu API của phần mềm nguồn xem có mục "Webhooks" hay "Event notifications" hay không.

Sau khi thiết lập, bước quan trọng nhất là gửi thử một sự kiện thật từ phần mềm nguồn (ví dụ tạo một đơn hàng test) và kiểm tra xem luồng automation có nhận được dữ liệu hay không, đồng thời xem qua cấu trúc dữ liệu thực tế nhận được - đây là bước nhiều người bỏ qua rồi mất thời gian debug sau này khi luồng không chạy đúng vì hiểu sai cấu trúc dữ liệu.

Bước 2: Gọi HTTP request có xác thực

Khi cần chủ động lấy hoặc gửi dữ liệu tới một phần mềm khác, bạn dùng khối "HTTP Request" có sẵn trên hầu hết nền tảng automation. Phần quan trọng nhất cần cấu hình đúng là xác thực (authentication) - phần lớn API yêu cầu bạn chứng minh mình có quyền truy cập trước khi trả dữ liệu, thường theo một trong ba cách phổ biến: gửi kèm API key trong header của request, dùng Bearer token (một chuỗi mã xác thực cấp cho tài khoản của bạn), hoặc quy trình OAuth phức tạp hơn (yêu cầu đăng nhập và cấp quyền qua trình duyệt trước khi lấy được token).

Tài liệu API của mỗi phần mềm sẽ ghi rõ phương thức xác thực cần dùng và tên chính xác của header cần gửi kèm (thường là "Authorization" hoặc một tên riêng theo từng nhà cung cấp). Một lỗi phổ biến của người mới là quên thêm đúng định dạng cho token (ví dụ nhiều API yêu cầu ghi "Bearer" trước token, thiếu từ này request sẽ bị từ chối dù token đúng), nên luôn đọc kỹ ví dụ mẫu (sample request) trong tài liệu API trước khi tự cấu hình.

Bước 3: Đọc dữ liệu JSON trả về

Kết quả trả về từ hầu hết API hiện đại đều ở định dạng JSON - một cấu trúc dữ liệu dạng cặp "tên trường: giá trị" lồng nhau, ví dụ dữ liệu khách hàng có thể trả về dạng tên, email nằm trong một cấu trúc lồng nhiều lớp. Các nền tảng automation đều có cách trích xuất từng trường cụ thể từ kết quả JSON này để dùng ở các bước tiếp theo trong luồng, thường bằng cách chọn trực tiếp trường cần lấy qua giao diện, hoặc gõ đường dẫn tới trường đó theo cú pháp riêng của từng nền tảng.

Cách kiểm tra nhanh khi mới làm quen là chạy thử request một lần, xem toàn bộ kết quả JSON trả về (hầu hết nền tảng đều hiển thị được), rồi xác định chính xác vị trí của trường dữ liệu bạn cần trước khi cấu hình bước tiếp theo - tránh đoán mò cấu trúc dữ liệu chỉ dựa vào tài liệu API, vì đôi khi kết quả thực tế có thêm hoặc thiếu trường so với tài liệu mô tả.

Bước 4: Xử lý lỗi thường gặp

Ba nhóm lỗi phổ biến nhất khi làm việc với HTTP request là: lỗi xác thực (mã lỗi 401 hoặc 403 - thường do token hết hạn hoặc sai định dạng, cần kiểm tra lại bước 2), lỗi dữ liệu gửi đi không đúng (mã lỗi 400 - thường do thiếu trường bắt buộc hoặc sai định dạng dữ liệu gửi lên, cần đối chiếu lại với tài liệu API), và lỗi từ phía hệ thống nguồn (mã lỗi 500 trở lên, hoặc timeout - phần mềm bên kia đang gặp sự cố hoặc quá tải, không phải lỗi từ luồng automation của bạn).

Với nhóm lỗi thứ ba, cách xử lý hợp lý là thiết lập cơ chế thử lại (retry) sau một khoảng thời gian ngắn thay vì để luồng dừng hẳn ngay lần đầu thất bại - hầu hết nền tảng automation đều có tuỳ chọn retry tự động cho khối HTTP request. Với cả ba nhóm lỗi, nên thiết lập thêm một kênh cảnh báo (ví dụ gửi tin nhắn vào nhóm chat nội bộ) khi luồng gặp lỗi liên tục nhiều lần, để có người kiểm tra kịp thời thay vì để luồng âm thầm chết mà không ai biết.

Ví dụ: nối một phần mềm trong nước chưa có connector

Giả sử công ty bạn dùng một phần mềm quản lý bán hàng trong nước không có sẵn trong thư viện kết nối của nền tảng automation, nhưng phần mềm này có tài liệu API công khai. Quy trình thực hiện sẽ là: đầu tiên, đăng nhập vào phần quản trị của phần mềm để lấy API key hoặc thông tin xác thực (thường nằm trong mục "Cài đặt" hoặc "Tích hợp"); tiếp theo, đọc tài liệu API để tìm đúng địa chỉ (endpoint) cho việc bạn cần làm, ví dụ "lấy danh sách đơn hàng mới trong ngày"; sau đó dựng khối HTTP request trên nền tảng automation, điền đúng địa chỉ endpoint, thêm API key vào header theo đúng định dạng tài liệu yêu cầu, và chạy thử để xem kết quả trả về.

Nếu phần mềm đó cũng hỗ trợ gửi webhook khi có đơn hàng mới (thay vì bạn phải chủ động hỏi theo lịch), cách làm còn gọn hơn: chỉ cần dán địa chỉ webhook của nền tảng automation vào phần cấu hình của phần mềm nguồn, rồi luồng sẽ tự động chạy ngay khi có đơn hàng mới phát sinh, không cần đợi tới lượt kiểm tra định kỳ.

Đây cũng chính là lý do vì sao các nền tảng automation dạng no-code vẫn hữu ích ngay cả khi thư viện kết nối sẵn có không phủ hết mọi phần mềm - miễn là phần mềm có API, node HTTP request luôn là phương án dự phòng đáng tin cậy. Nếu bạn muốn hiểu rõ hơn khái niệm nền tảng no-code trước khi áp dụng kỹ thuật này, bài Nền tảng no-code là gì và vì sao doanh nghiệp nhỏ cần biết giải thích khái niệm này một cách dễ hiểu hơn.

Lưu ý bảo mật khi dùng webhook và API key

Địa chỉ webhook và API key đều là những thông tin nhạy cảm cần bảo vệ như mật khẩu - bất kỳ ai có được địa chỉ webhook của bạn cũng có thể gửi dữ liệu giả vào luồng automation, còn ai có được API key có thể truy cập trực tiếp vào dữ liệu của phần mềm nguồn. Nguyên tắc an toàn cơ bản là không bao giờ dán API key trực tiếp vào tài liệu chia sẻ công khai (kể cả trong nhóm chat nội bộ nếu không cần thiết), và nên dùng tính năng lưu trữ thông tin xác thực riêng (credential storage) có sẵn trên các nền tảng automation thay vì gõ trực tiếp vào từng khối cấu hình.

Với webhook, nếu nền tảng cho phép thêm một lớp xác thực (ví dụ yêu cầu một mã bí mật kèm theo mỗi lần gửi dữ liệu), nên bật tính năng này để tránh trường hợp có người đoán được địa chỉ webhook và gửi dữ liệu giả mạo vào luồng của bạn. Ngoài ra, nên định kỳ (ví dụ mỗi 6 tháng) thay mới API key đang dùng, đặc biệt với những key có quyền truy cập vào dữ liệu tài chính hoặc thông tin khách hàng.