Nango: khi nào nên giao OAuth và đồng bộ API của khách cho một lớp chung, khi nào nên tự viết

Theo một bài kỹ thuật Nango tự đăng tháng 8/2026, 16% số commit vào cấu hình provider của họ là để sửa lỗi. Đây là số liệu do chính nhà cung cấp công bố, từ một công ty vận hành phần xác thực cho hơn 1.000 API.

Dù vậy, nó vẫn cho thấy tích hợp không phải việc viết một lần là xong: cứ thêm một nhà cung cấp là thêm một thứ phải trông nom mãi về sau.

Thử hình dung bạn là FDE và khách muốn agent của họ đọc Jira, ghi vào Airtable, nghe webhook từ CRM. Ngày đầu trôi qua nhanh, nhưng đến tuần thứ ba thì các connection bắt đầu chết mà không báo lỗi. Việc trông giữ connection từ sau ngày đầu chính là thứ Nango muốn nhận thay bạn.

Nango thực sự nhận những việc gì?

Theo tài liệu chính thức, Nango lo OAuth, API key, làm mới token, scope, phân quyền và lưu credential. Đây đúng là phần mà các team thường tự viết. Ngoài xác thực, Nango còn ba khối việc nữa, và khối đầu là sync: giữ cho dữ liệu từ API bên ngoài luôn mới trong sản phẩm, trong pipeline RAG hoặc trong workflow phát hiện thay đổi.

Function phục vụ các lệnh đọc và ghi theo yêu cầu (action). Webhook của nhà cung cấp đi qua Nango, rồi được chuyển tiếp hoặc xử lý bằng function, nên bạn không phải dựng endpoint riêng cho từng nhà cung cấp.

Một ví dụ: token xoay vòng làm hỏng mọi thứ ra sao

Thử hình dung bạn tự viết connector cho Atlassian. Hai worker cùng phát hiện access token sắp hết hạn và cùng gửi yêu cầu refresh. Worker A nhận về cặp token mới, và đúng lúc đó refresh token cũ mà worker B đang cầm bị vô hiệu hoá.

Yêu cầu của B thất bại, và nếu code của bạn ghi đè credential bằng kết quả của B, connection coi như chết. Người dùng cuối phải kết nối lại từ đầu.

Kịch bản này không phải chuyện hiếm. Nango ghi nhận rằng nhiều nhà cung cấp, trong đó có Airtable và Atlassian, vô hiệu hoá refresh token cũ ngay khi cấp token thay thế.

Muốn tự làm cho đúng, bạn cần khoá theo từng connection, ghi token theo kiểu nguyên tử và có cơ chế thử lại. Chữ “nhiều” trong ghi nhận trên cũng có nghĩa là không phải tất cả, nên bạn phải kiểm tra hành vi này với từng nhà cung cấp một.

Có một cái bẫy khó thấy hơn: lỗi xác thực không phải lúc nào cũng trông giống lỗi. Một số API trả HTTP 200 ngay cả khi xác thực thất bại. Client tự viết chỉ kiểm tra status code sẽ báo mọi thứ ổn, trong khi sync thực ra đang kéo về dữ liệu rỗng.

Khi nào nên dùng Nango, khi nào nên tự viết?

Nango hợp nhất khi số nhà cung cấp nhiều và số khách hàng cuối kết nối cũng nhiều. Khi đó công bảo trì cho từng nhà cung cấp, đúng thứ Nango bán, sẽ lớn hơn chi phí học và phụ thuộc vào một nền tảng.

Nếu agent của khách cần mười connector và mỗi connector cần sync cùng webhook, giao lớp này cho Nango giúp bạn dồn thời gian vào logic nghiệp vụ.

Ngược lại, nếu khách chỉ cần một hai API nội bộ hoặc một nhà cung cấp có xác thực đơn giản, tự viết thường gọn hơn. Ngay cả khi số connector lớn, vẫn còn ba điểm khiến bạn nên dừng lại cân nhắc.

Điểm đầu tiên là giấy phép. Nango dùng Elastic License, và dù README gọi đây là mã nguồn mở, giấy phép này không được OSI công nhận, nên bộ phận pháp lý của khách sẽ muốn đọc kỹ.

Điểm tiếp theo là nơi chạy. Theo trang giá, phương án chạy Nango trong hạ tầng của chính khách thuộc gói Enterprise. Nếu khách bắt buộc dữ liệu phải nằm trong hạ tầng của họ, hãy nêu điều này ngay trong buổi làm việc đầu tiên.

Điểm cuối là chi phí. Gói miễn phí có giới hạn cứng, còn gói trả theo mức dùng bắt đầu từ 50 USD mỗi tháng kèm 50 USD credit, tính 0,29 USD cho mỗi connection, 0,72 USD mỗi giờ compute và 0,5 USD mỗi GB dữ liệu truyền.

Tính thử một con số

Giả sử sản phẩm của khách có 50 khách hàng cuối, mỗi khách nối 10 connector. Đó là 500 connection, tức 500 × 0,29 = 145 USD tiền connection, chưa kể compute và dữ liệu truyền. Nếu số khách hàng cuối tăng lên 500, con số này thành 5.000 connection và 1.450 USD.

Phép tính này cho thấy biến số quyết định không phải số connector mà là số khách hàng cuối nhân với số connector. Hãy đặt con số đó cạnh số giờ kỹ sư mà team khách đang phải bỏ ra để sửa connector, và kiểm tra lại trang giá trước khi đưa vào đề xuất, vì bảng giá có thể thay đổi.

Con số 16% và danh sách các kiểu lỗi ở trên mô tả đúng loại rủi ro, nhưng đừng coi chúng là số liệu đo trên hệ thống của khách bạn.

Nên học gì trước?

Hãy học OAuth đến tận cùng trước khi học bất kỳ công cụ nào. Bạn cần hiểu luồng authorization code, sự khác nhau giữa access token và refresh token, cách xoay vòng token, và cách phát hiện lỗi xác thực ẩn sau một phản hồi 200.

Có nền này rồi, bạn mới đánh giá được Nango đang giúp mình bớt việc gì, và tự xử lý được khi một connection hỏng ngoài giờ làm việc.

Về sự nghiệp, khi đọc mô tả công việc FDE, để ý các cụm như “integrations”, “connectors” hay “agent tools”. Đó là dấu hiệu team đang phải gánh đúng phần việc này. Trong CV, đừng chỉ ghi “tích hợp Jira”.

Hãy ghi bạn đã xử lý token xoay vòng thế nào, đã phát hiện lỗi xác thực ẩn ra sao, và vì sao chọn dùng hay không dùng một lớp chung. Nhà tuyển dụng cần thấy bạn có phán đoán khi chọn dùng hay tự viết, chứ không chỉ biết dùng thêm một công cụ.

Ở chỗ khách, câu nên hỏi đầu tiên là sang năm sẽ có bao nhiêu connector và bao nhiêu khách hàng cuối nối vào, chứ chưa phải dùng Nango hay không.