Google Ads API đã đổi cách quản lý quyền truy cập: từ ngày 9/9/2026, developer token không còn là căn cứ xác định cấp quyền của dự án. Quyền truy cập hiện gắn với Google Cloud Project tạo thông tin xác thực OAuth. Với nhiều hệ thống đang chạy, chưa cần dừng chiến dịch để sửa code ngay; nhưng đội kỹ thuật nên kiểm tra project đang dùng và cấp độ API được gán.

Thay đổi này đáng chú ý với agency, doanh nghiệp có dashboard quảng cáo riêng và nhóm vibecoding đang thử nối Claude, Antigravity hoặc Codex vào quy trình Google Ads. Nó giảm một bước quản trị cũ, chứ không biến việc chạy quảng cáo thành thao tác “có tiền là chạy”.

Doanh nghiệp muốn đưa các luồng AI từ thử nghiệm vào vận hành có thể tham khảo dịch vụ phát triển ứng dụng AI từ Google AI Studio sang Production để hình dung thêm các yêu cầu về tích hợp, phân quyền và vận hành ổn định.

Google Ads API bỏ developer token: thay đổi điều gì?

Google đã sunset developer token vào ngày 9/9/2026. Trước đó, token 22 ký tự là đầu mối gắn với quyền API. Sau thay đổi, cấp truy cập được quyết định bởi Google Cloud Project đứng sau OAuth client ID/secret hoặc service account mà ứng dụng sử dụng.

Token cũ có thể vẫn nằm trong header request, nhưng máy chủ Google sẽ bỏ qua. Ứng dụng hiện tại vì thế tiếp tục hoạt động mà chưa cần thay đổi ngay. Tuy vậy, Google khuyến nghị cập nhật thư viện và bỏ dần trường developer token; một phiên bản API lớn trong tương lai có thể từ chối token được gửi kèm.

Không phải quyền nào cũng tự động giống nhau

Với nhà phát triển hiện hữu, Google chuyển cấp độ quyền đang hoạt động sang những Cloud Project đã gọi API bằng token tương ứng trong 90 ngày trước mốc sunset. Dự án mới, dự án ít hoạt động hoặc chưa từng được dùng có thể chỉ có Test access. Vì vậy, câu hỏi quan trọng không còn là “token của mình còn không?” mà là “đúng project đang được ứng dụng dùng có cấp truy cập cần thiết chưa?”.

Hệ thống cũ có cần sửa ngay không?

Thông thường là chưa. Nếu ứng dụng đang chạy ổn, request vẫn có thể gửi token cũ và Google tiếp tục xử lý. Không cần thay đồng loạt cấu hình đang phục vụ chiến dịch chỉ vì thông báo sunset.

Nhưng “chưa cần sửa” không đồng nghĩa với “có thể bỏ qua”. Khi thay máy chủ, tạo OAuth credentials mới, chuyển project hoặc nâng phiên bản thư viện, cấu hình quyền có thể khác. Một job đồng bộ báo cáo vẫn chạy trên project cũ, trong khi tính năng mới lại dùng project mới chỉ có Test access. Lỗi thường chỉ lộ ra khi gọi tài khoản production.

• Ghi lại Cloud Project đang sở hữu OAuth client ID/secret hoặc service account của ứng dụng.
• Mở Google Ads API Overview trong Google Cloud Console và kiểm tra access level của đúng project.
• Xác nhận tài khoản Google Ads đích, người dùng OAuth và quyền IAM quản trị project.
• Nếu ứng dụng dùng thư viện Google Ads, xem changelog và lên lịch nâng phiên bản để bỏ khai báo developer token khi phù hợp.
• Thử trên môi trường kiểm soát trước khi cập nhật luồng đang tiêu ngân sách thật.

Đăng ký hoặc nâng cấp quyền ở đâu?

Developer mới đăng ký quyền Google Ads API từ Google Cloud Console, tại trang tổng quan Google Ads API của project. Quy trình xin cấp hoặc nâng access level trong API Center của tài khoản quản lý Google Ads đã được chuyển đi; API Center giờ chủ yếu để xem lại thông tin developer cũ.

Quyền Test, Explorer, Basic hoặc Standard vẫn có giới hạn và quy trình riêng. Việc chọn cấp độ cần khớp với mục đích sử dụng và chính sách Google Ads API. Với một số cấp như Basic hoặc Standard, Google có thể yêu cầu xác minh thương hiệu của project. Người quản trị cũng nên cập nhật owner/editor và email liên hệ trong IAM để nhận thông báo chính sách.

Đừng nhầm quyền API với ngân sách quảng cáo. Ngân sách quyết định giới hạn chi tiêu chiến dịch; quyền API quyết định ứng dụng có thể gọi các chức năng được phép hay không. Để tự động tạo hoặc chỉnh sửa chiến dịch, hệ thống còn phải qua OAuth, có quyền trên tài khoản Ads phù hợp, tuân thủ chính sách và được kiểm tra trước khi thực thi.

Claude, Antigravity và Codex có thể hỗ trợ vibeads đến đâu?

Các trợ lý lập trình có thể giúp viết connector, truy vấn báo cáo, dựng bản nháp chiến dịch hoặc tạo luồng kiểm tra dữ liệu. Khi kết nối Google Ads API, chúng vẫn cần một lớp tích hợp được cấu hình đúng: thông tin xác thực OAuth, Cloud Project có quyền phù hợp, tài khoản khách hàng đúng và phạm vi thao tác được giới hạn.

Với nhóm nhỏ, một thử nghiệm an toàn có thể bắt đầu bằng báo cáo chỉ đọc: lấy chi phí, lượt chuyển đổi và trạng thái quảng cáo, sau đó yêu cầu người phụ trách đối chiếu với giao diện Google Ads. Khi chuyển sang tạo hoặc sửa chiến dịch, nên thêm bước duyệt của con người, giới hạn ngân sách theo ngày và ghi log thao tác. Đừng đưa khóa truy cập vào prompt hoặc kho mã công khai.

Nói ngắn gọn: vibecoding làm giảm công sức dựng công cụ, không xóa bỏ trách nhiệm quản trị Ads. Một AI có thể đề xuất đặt giá thầu; người vận hành vẫn cần kiểm tra mục tiêu, tracking, trang đích và mức chi được phép.

DPS.MEDIA khuyến nghị đội marketing chuẩn bị gì?

Hãy bắt đầu bằng một bảng kiểm kê nhỏ: ứng dụng nào đang gọi API, mỗi ứng dụng dùng Cloud Project nào, quyền đang ở cấp nào và ai phụ trách IAM. Sau đó, tách thử nghiệm khỏi môi trường chạy thật để việc thay credential hoặc nâng thư viện không làm gián đoạn báo cáo.

Nếu đang thử Claude, Antigravity hay Codex, hãy mô tả rõ phạm vi cho công cụ: đọc báo cáo, đề xuất nội dung, hay được phép gửi thay đổi lên tài khoản. Phân quyền tối thiểu và quy trình phê duyệt vẫn quan trọng hơn tốc độ tạo code.

Google Ads API đang chuyển từ mô hình xoay quanh developer token sang quyền gắn với Cloud Project. Hệ thống cũ có thể tiếp tục chạy, nhưng project, access level và thư viện nên được rà soát trước lần nâng cấp hoặc mở rộng tích hợp kế tiếp. Xem hướng dẫn chính thức về thay đổi developer token của Google Ads API để đối chiếu quy trình mới nhất.

DPS.MEDIA hỗ trợ doanh nghiệp xây dựng giải pháp marketing và ứng dụng AI theo quy trình có phân quyền, kiểm soát và đo lường. Tìm hiểu thêm tại DPS.MEDIA hoặc liên hệ Hotline/Zalo 0961 545 445.