Bất kỳ ai ước tính chi phí phát triển API tùy chỉnh dựa trên số lượng endpoint đều sẽ sai, và thường sai gấp ba lần. Endpoint là phần rẻ nhất trong toàn bộ công việc. Một tá endpoint chỉ đọc và ghi dữ liệu mà bạn vốn đã nắm giữ là công việc chừng hai tuần của một lập trình viên backend có nghề.

Thứ thực sự tốn tiền là tất cả những gì biến đám endpoint đó thành một hạ tầng mà một công ty khác dám đặt hoạt động kinh doanh của họ lên trên: cơ chế xác thực chịu được một đợt rà soát bảo mật, cách quản lý phiên bản cho phép bạn đổi ý về sau, tài liệu đủ tốt để không ai phải gửi email hỏi bạn, và bộ máy vận hành cho bạn biết khách hàng nào đang có một buổi sáng tồi tệ. Khoảng cách giữa việc có một API và việc có một API mà người khác dựa vào để làm ăn chính là nơi ngân sách nằm.

Các mức giá nhìn thoáng qua: Một API nội bộ chỉ do ứng dụng của chính bạn gọi thường tốn từ 10.000 đến 30.000 bảng Anh. Một API dành cho đối tác, phục vụ một nhóm nhỏ các bên tích hợp đã được nêu tên, thường rơi vào khoảng 40.000 đến 100.000 bảng Anh. Một API công khai là một phần của sản phẩm, có đăng ký tự phục vụ và hợp đồng được công bố, khởi điểm quanh mức 100.000 bảng Anh và vẫn tiếp tục tốn tiền sau khi ra mắt.

Bạn thực sự đang mua những gì

API là một sản phẩm có người dùng, và nó cần đúng những thứ mà một sản phẩm cần. Đối chiếu danh sách dưới đây với một bản báo giá là cách nhanh nhất để thấy thứ gì đã bị bỏ ra ngoài.

Thiết kế và bản giao kèo. Phải có người quyết định mô hình tài nguyên, quy ước đặt tên, định dạng lỗi, cách phân trang và cú pháp lọc, rồi viết tất cả xuống thành một đặc tả trước khi bắt tay vào hiện thực. Bỏ qua bước này sẽ cho ra một API mà ba endpoint giải quyết cùng một vấn đề theo ba cách khác nhau, và bên tích hợp nhận ra điều đó ngay lập tức.

Xác thực và phân quyền. Khóa API thì đơn giản và phù hợp cho mục đích nội bộ. API cho đối tác và API công khai nói chung cần một luồng dựa trên token đàng hoàng, có phạm vi, có hạn dùng và có cơ chế xoay vòng, cộng thêm quyền hạn riêng cho từng bên tiêu thụ được kiểm tra trên mỗi yêu cầu chứ không suy đoán từ chiếc khóa.

Giới hạn tần suất và hạn mức. Giới hạn theo từng bên tiêu thụ bảo vệ hạ tầng của bạn khỏi một tác vụ chạy loạn của một đối tác tích hợp. Chúng cũng cần được thông báo trong các header phản hồi để những client cư xử tử tế biết tự lùi lại, và cần một lối ngoại lệ cho khách hàng thực sự có nhu cầu chính đáng dùng nhiều hơn.

Những phần mà bên tích hợp đem ra chấm điểm

Tài liệu. Một trang tham chiếu sinh tự động chỉ là điều kiện tối thiểu. Thứ bên tiêu thụ thực sự cần là hướng dẫn bắt đầu, phần dẫn dắt về xác thực, ví dụ chạy được bằng một vài ngôn ngữ và một nhật ký thay đổi. Tài liệu tốt là một hạng mục bàn giao có thật, đo bằng tuần, và nó là khác biệt giữa một API tự lan ra và một API sinh phiếu hỗ trợ mãi mãi.

Môi trường thử nghiệm. Đối tác sẽ không kiểm thử trên môi trường thật, và bạn cũng không nên muốn họ làm vậy. Một môi trường thử nghiệm với dữ liệu sát thực tế, trạng thái có thể đặt lại và cùng bộ quy tắc kiểm tra là hạng mục hay bị bỏ sót nhất trong một bản báo giá API, đồng thời là tính năng hay bị đòi nhất sau khi ra mắt.

Khả năng quan sát. Bạn cần nhìn thấy lưu lượng yêu cầu, tỷ lệ lỗi và độ trễ tách theo từng bên tiêu thụ, bởi câu than phiền rằng API chậm chỉ hành động được khi bạn nói được yêu cầu của ai đang chậm. Những mã định danh tương quan cho phép bạn lần theo một cuộc gọi hỏng của một khách hàng cụ thể xuyên qua nhật ký sẽ hoàn vốn ngay trong tháng hỗ trợ đầu tiên.

Kiểm thử. Ngoài kiểm thử đơn vị, một API cần các bài kiểm thử giao kèo làm hỏng bản dựng khi hình dạng phản hồi thay đổi ngoài ý muốn. Chính tấm lưới an toàn đó cho phép bạn tiếp tục phát triển mà không làm gãy những bên tích hợp đã tin bạn.

Ba bậc, và vì sao chúng chênh nhau đến vậy

Cùng một bộ endpoint có chi phí rất khác nhau tùy vào ai là người dùng nó, bởi đối tượng sử dụng quyết định mức chịu đựng đối với sự chưa hoàn hảo.

API nội bộ phục vụ chính các ứng dụng của bạn. Đội của bạn kiểm soát cả hai đầu, các thay đổi phá vỡ tương thích có thể phối hợp trước, tài liệu có thể vắn tắt và việc xác thực có thể dựa vào ranh giới mạng. Chi phí điển hình cho một dịch vụ được dựng tử tế, có kiểm thử và giám sát hợp lý, là từ 10.000 đến 30.000 bảng Anh.

API cho đối tác phục vụ một tập hợp các tổ chức bên ngoài đã biết trước. Lúc này bạn cần xác thực thật sự, thông điệp lỗi có ý nghĩa, một môi trường thử nghiệm, tài liệu viết ra hẳn hoi và một chính sách phiên bản, bởi bạn không thể triển khai một thay đổi phá vỡ tương thích vào chiều thứ Ba rồi mong mọi người theo kịp. Chi phí điển hình là từ 40.000 đến 100.000 bảng Anh, tùy số lượng tài nguyên và mức độ khắt khe của các yêu cầu bảo mật.

API công khai hoặc API sản phẩm phục vụ bất kỳ ai đăng ký. Đăng ký tự phục vụ, quản lý khóa, giới hạn tần suất được công bố, một trang trạng thái, cơ chế đo lường theo mức dùng, tài liệu đầy đủ và một quy trình hỗ trợ đều trở thành bắt buộc. Nếu việc tính tiền phụ thuộc vào mức dùng, bạn còn gánh thêm một hệ thống đo đếm và đối soát. Chi phí điển hình là từ 100.000 bảng Anh trở lên, và ngày ra mắt là điểm khởi đầu của khoản chi chứ không phải điểm kết thúc.

Quyết định một cách trung thực xem bạn đang xây bậc nào là nửa giờ giá trị nhất của cả dự án. Phần lớn các vụ vượt ngân sách trong hạng mục này đến từ việc khoanh phạm vi cho một API nội bộ rồi ba tháng sau mới phát hiện ra rằng vốn dĩ vẫn luôn có một đối tác sẽ dùng nó.

Chi phí phát triển API tùy chỉnh thực sự đi đâu

Với một API cấp đối tác, công sức phân bổ theo một cách khá dễ đoán, và hiếm khi giống điều các bên liên quan hình dung.

Khoảng một phần năm dành cho thiết kế và đặc tả, bao gồm cả những cuộc tranh luận về cách đặt tên tài nguyên nghe có vẻ phí thời gian nhưng lại ngăn được nhiều tháng thiếu nhất quán. Thêm chừng một phần năm nữa dành cho phần hiện thực các endpoint, tức đúng cái phần mà mọi người hình dung khi họ duyệt ngân sách.

Xác thực, phân quyền và giới hạn tần suất gộp lại thường chiếm mười lăm đến hai mươi phần trăm, và nhiều hơn nếu bạn phải tích hợp với một nhà cung cấp danh tính sẵn có vốn có quan điểm riêng. Tài liệu, môi trường thử nghiệm và các thư viện client chiếm một phần tương đương, con số làm nhiều người ngạc nhiên cho đến khi họ thử tự viết một hướng dẫn bắt đầu cho ra hồn.

Kiểm thử, khả năng quan sát và triển khai tiêu hết phần còn lại. Chính một phần tư cuối cùng đó là phần dễ bị cắt nhất khi hạn chót đến gần, và việc cắt nó là thứ biến một khoản chi phí xây dựng một lần thành một gánh nặng hỗ trợ vĩnh viễn.

Để thấy khoản này nằm ở đâu bên cạnh phần còn lại của ngân sách bàn giao, bài Chi phí phát triển phần mềm tùy chỉnh: Hướng dẫn lập ngân sách 2026 bao quát các hạng mục xung quanh.

Những quyết định làm con số nhảy

Một số ít lựa chọn giải thích phần lớn khoảng chênh giữa các bản báo giá.

Đồng bộ hay bất đồng bộ. Nếu có thao tác nào mất hơn một hai giây, bạn cần một mô hình tác vụ: nhận yêu cầu, trả về một mã tham chiếu, rồi để bên tiêu thụ hỏi lại hoặc nhận một lời gọi ngược. Đó là một khối lượng xây dựng lớn hơn hẳn so với một cặp yêu cầu và phản hồi đơn giản, và việc cung cấp webhook nghĩa là bạn đang vận hành một hệ thống chuyển phát riêng, có thử lại, có xác minh chữ ký và có kho lưu các bản tin không giao được.

Đa khách thuê. Bảo đảm rằng một khách hàng không bao giờ nhìn thấy dữ liệu của khách hàng khác là điều dễ mô tả và dễ làm sai một cách tinh vi. Làm cho đúng, với việc kiểm tra phân quyền ở tầng truy cập dữ liệu thay vì trong từng controller, làm tăng chi phí và không phải là tùy chọn.

Nghĩa vụ tuân thủ. Xử lý dữ liệu cá nhân, thông tin thanh toán hay thông tin sức khỏe kéo theo nhật ký kiểm toán, quy tắc lưu trữ, yêu cầu mã hóa và việc thu thập bằng chứng. Những thứ này hiếm khi có trong bản ước tính ban đầu và không bao giờ có thể mặc cả về sau.

Cam kết mức dịch vụ. Một API có mục tiêu sẵn sàng ghi trong hợp đồng cần dự phòng, cảnh báo và người trực. Đó là chi phí vận hành chứ không phải chi phí xây dựng, và nên được báo giá riêng để không ai bị bất ngờ.

Nền móng sẵn có. Xây trên một mã nguồn đã có sẵn xác thực, tác vụ nền và giám sát thì rẻ hơn rất nhiều so với bắt đầu từ con số không. Nếu bạn cần luôn cả nền tảng bên dưới, bài hướng dẫn Xây dựng Cloudflare Workers API: hướng dẫn serverless 2026 trình bày một cách làm giữ cho chi phí hạ tầng ở mức thấp.

Những khoản chi kéo đến sau ngày ra mắt

Một API là một lời hứa, và lời hứa thì có chi phí duy trì.

Quản lý phiên bản là khoản lớn nhất. Một khi bên tiêu thụ bên ngoài đã phụ thuộc vào hình dạng phản hồi của bạn, bạn không còn tự do thay đổi chúng. Duy trì song song hai phiên bản trong lúc các bên tích hợp chuyển đổi là chuyện bình thường, và điều đó có nghĩa là mọi bản vá lỗi phải được áp dụng hai lần trong một quãng thời gian. Một chính sách ngừng hỗ trợ được công bố với thời hạn báo trước rộng rãi khiến việc này còn quản được; không có chính sách đó thì mọi cải tiến đều thành một cuộc thương lượng.

Hỗ trợ là khoản thứ hai. Ngay cả tài liệu xuất sắc cũng sinh ra câu hỏi, và những câu hỏi đó đủ kỹ thuật để đi thẳng tới một lập trình viên thay vì dừng lại ở bộ phận chăm sóc khách hàng. Hãy dành ngân sách cho thời gian kỹ sư thật sự, đặc biệt trong những tháng ngay sau khi mỗi đối tác mới lên sóng.

Bảo trì tài liệu là khoản thứ ba và cũng là khoản bị bỏ bê nhất. Những ví dụ không còn chạy được thì tệ hơn là không có ví dụ, và chúng bào mòn niềm tin nhanh hơn cả một sự cố ngừng dịch vụ.

Như một con số để lập kế hoạch, hãy dự trù mười lăm đến hai mươi lăm phần trăm chi phí xây dựng ban đầu mỗi năm để giữ một API đối tác hoặc API công khai khỏe mạnh. Nếu bản thân API là một nguồn doanh thu, bài Mô hình cấp phép phần mềm: Hướng dẫn doanh nghiệp 2026 bàn về cách dựng phần thương mại.

Làm sao để dự án không đội lên gấp đôi

Ba thói quen giữ các dự án API nằm trong phạm vi ước tính.

Hãy viết đặc tả trước và để một bên tiêu thụ thật sự soát lại trước khi bắt đầu hiện thực. Một giờ góp ý từ đội sẽ thực sự tích hợp giúp tiết kiệm nhiều tuần làm lại, và nó lôi ra đúng cái yêu cầu chưa ai nhắc tới.

Hãy làm trọn vẹn một endpoint, đi hết qua xác thực, xử lý lỗi, tài liệu, kiểm thử và giám sát, trước khi làm hai mươi endpoint còn lại. Cái đầu tiên sẽ tiết lộ chi phí thật cho mỗi endpoint, và nó tiết lộ vào lúc ngân sách vẫn còn hấp thụ được tin đó.

Hãy tàn nhẫn với danh sách tài nguyên ban đầu. Phần lớn API ra mắt với nhiều endpoint hơn số mà bất kỳ ai dùng tới, và mỗi endpoint không được dùng vẫn cần viết tài liệu, kiểm thử, bảo vệ và quản lý phiên bản chừng nào nó còn tồn tại. Hãy phát hành bề mặt hữu ích nhỏ nhất rồi mở rộng khi mức sử dụng thật cho bạn biết còn thiếu gì.

Xây một API mà người ta muốn tích hợp

Mecanik thiết kế và xây dựng API như một phần của dịch vụ phát triển phần mềm tùy chỉnh , từ những dịch vụ nội bộ cho tới các API sản phẩm công khai có đăng ký tự phục vụ. Chúng tôi coi đặc tả, tài liệu và môi trường thử nghiệm là hạng mục bàn giao chứ không phải chuyện tính sau, bởi chính chúng quyết định liệu có ai tích hợp thành công hay không.

Nếu bạn đang ở phía bên kia của vấn đề này, tức là tiêu thụ API của người khác thay vì công bố API của mình, bài Tích hợp API bên thứ ba: chi phí và kiểu lỗi nói về những gì cần để mắt tới. Còn nếu không, hãy cho chúng tôi biết ai là bên tiêu thụ và họ cần làm gì, chúng tôi sẽ khoanh phạm vi theo từng bậc để bạn thấy chính xác mỗi mức tham vọng tốn bao nhiêu.

Bài viết liên quan: Thuê ngoài phát triển phần mềm tại Vương quốc Anh , Tích hợp CRM và ERP: chi phí, cách làm, cạm bẫy , Hiện đại hóa mainframe: rewrite, refactor hay replatform .

Câu hỏi thường gặp

Chi phí phát triển API tùy chỉnh là bao nhiêu? Một API nội bộ thường tốn từ 10.000 đến 30.000 bảng Anh, một API cho đối tác từ 40.000 đến 100.000 bảng Anh, và một API sản phẩm công khai từ 100.000 bảng Anh trở lên. Đối tượng sử dụng quyết định giá nhiều hơn hẳn số lượng endpoint, bởi bên tiêu thụ bên ngoài đòi hỏi tài liệu, môi trường thử nghiệm, quản lý phiên bản và hỗ trợ.

Xây một API tùy chỉnh mất bao lâu? Một dịch vụ nội bộ thường mất từ bốn đến tám tuần. Một API cấp đối tác nói chung mất từ ba đến năm tháng, bao gồm cả tài liệu và một môi trường thử nghiệm. Các API công khai có đăng ký tự phục vụ và đo lường mức dùng thường mất sáu tháng hoặc hơn mới ra mắt được.

Điều gì khiến việc phát triển API đắt hơn dự kiến? Tài liệu, môi trường thử nghiệm, giới hạn tần suất theo từng bên tiêu thụ, việc hỗ trợ nhiều phiên bản và khả năng quan sát. Những hạng mục này hiếm khi xuất hiện trong các bản ước tính ban đầu, nhưng gộp lại chúng thường chiếm một nửa tổng công sức của một API cho đối tác hoặc API công khai.

Nên xây API theo REST hay GraphQL? REST vẫn là lựa chọn mặc định an toàn hơn cho API đối tác và API công khai, vì công cụ, khả năng lưu đệm và mức quen thuộc của lập trình viên đều rộng hơn. GraphQL hợp với dùng nội bộ và các ứng dụng client giàu tính năng, nơi bên tiêu thụ cần truy vấn linh hoạt, tuy nhiên nó dịch chi phí sang phần giới hạn độ phức tạp truy vấn và phân quyền.

Sau khi ra mắt một API thì nên dự trù những chi phí thường xuyên nào? Hãy dự trù mười lăm đến hai mươi lăm phần trăm chi phí xây dựng mỗi năm. Khoản đó chi cho việc duy trì song song nhiều phiên bản trong thời gian ngừng hỗ trợ, thời gian kỹ sư trả lời các câu hỏi tích hợp, việc cập nhật tài liệu và phần giám sát cần thiết để phục vụ bên tiêu thụ bên ngoài.