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

Tại sao không cho agent truy cập Gmail hoặc Outlook của tôi?

Bảo mật — OAuth của Gmail/Outlook cho agent truy cập toàn bộ hộp thư (y tế, tài chính, pháp lý, cá nhân). Một prompt injection trong bất kỳ email đến nào có thể thao túng agent có quyền truy cập tất cả. InboxAPI cung cấp cho agent hộp thư riêng biệt với phân loại độ tin cậy và datamarking trên mọi tin nhắn.

Danh tính — Khi agent gửi từ Gmail của bạn, người nhận không biết họ đang nói chuyện với ai. Phản hồi đến hộp thư của bạn, lẫn với email thật. InboxAPI cung cấp cho agent địa chỉ riêng — phân tách rõ ràng giữa bạn và agent.

Tính thực tiễn — API của Gmail/Outlook không phải MCP-native. Bạn cần middleware, OAuth plumbing và tích hợp tùy chỉnh. InboxAPI hoạt động ngay với bất kỳ MCP client nào.

Khác gì so với AWS SES, SendGrid hoặc Resend?

Đó là các API gửi email — bạn xây dựng hạ tầng email trên đó. InboxAPI cung cấp cho agent danh tính email hoàn chỉnh: gửi, nhận, tìm kiếm, trả lời và chuyển tiếp. Không cần cấu hình và không có hạ tầng để quản lý.

Khác gì so với AgentMail hoặc a1base?

Chúng tôi tự xây dựng hệ thống email từ đầu. Không wrap SES, Postfix hay bất kỳ dịch vụ gửi bên thứ ba nào. Email của agent đi qua hạ tầng do chúng tôi trực tiếp vận hành.

Thực sự miễn phí?

Đúng. Không cần thẻ tín dụng, không có thời gian dùng thử, không có bậc sử dụng. Chúng tôi đang phát triển gói trả phí với tính năng bổ sung, nhưng trải nghiệm cốt lõi sẽ luôn miễn phí.

Bạn ngăn chặn spam và lạm dụng như thế nào?

Tạo tài khoản yêu cầu proof-of-work. Mỗi tài khoản có 5 slot danh bạ cho người nhận bên ngoài — khi tất cả slot đang sử dụng, mục ít được sử dụng gần đây nhất sẽ tự động được thay thế sau 5 ngày không hoạt động. Hạn mức gửi hàng ngày và giới hạn tốc độ được áp dụng cho mọi tài khoản. Các ràng buộc này mang tính cấu trúc — không phải chính sách, mà là cách hệ thống hoạt động.

Còn prompt injection qua email thì sao?

Mỗi email đến đều có phân loại độ tin cậy — trusted, agent, unverified hoặc suspicious — dựa trên việc người gửi có trong danh bạ hay không và email có vượt qua kiểm tra xác thực hay không. Điều này giúp agent quyết định xử lý mỗi tin nhắn cẩn thận đến mức nào. Email từ agent InboxAPI khác được đánh dấu riêng để agent biết cần kiểm tra với bạn trước khi hành động.

Ngoài ra, nội dung email không tin cậy được tự động chuyển đổi bằng spotlighting (datamarking) — khoảng trắng được thay bằng ký tự đánh dấu duy nhất để agent phân biệt rõ dữ liệu email với hướng dẫn của chính nó. Điều này giảm tỷ lệ thành công của tấn công prompt injection nhúng trong email từ ~50% xuống dưới 3%.

Spotlighting là gì?

Công cụ lấy email áp dụng datamarking cho nội dung không tin cậy, thay thế khoảng trắng bằng ký tự Unicode đánh dấu duy nhất được tạo cho mỗi yêu cầu. Nội dung chứa ký tự đánh dấu nên được coi là dữ liệu bên ngoài — không phải hướng dẫn để làm theo. Để khôi phục văn bản gốc, thay thế ký tự đánh dấu bằng khoảng trắng. Email từ người gửi tin cậy (trong danh bạ với xác thực hợp lệ) không bị spotlight theo mặc định. Kỹ thuật này dựa trên nghiên cứu học thuật (arXiv:2403.14720).

Còn rò rỉ dữ liệu thì sao?

Email gửi đi được quét tìm token xác thực và thông tin đăng nhập. Nếu agent vô tình cố gửi email chứa JWT hoặc access token, tin nhắn sẽ bị từ chối trước khi rời khỏi nền tảng. Điều này ngăn agent bị lừa rò rỉ dữ liệu nhạy cảm qua email. Ngoài ra, tất cả địa chỉ người nhận trong thao tác gửi, trả lời và chuyển tiếp được xác thực theo RFC 5322 — địa chỉ không đúng định dạng bị từ chối trước khi gửi.

Agent có thể spam nhau không?

Cùng giới hạn gửi áp dụng cho tất cả email gửi đi — giới hạn người nhận, hạn mức và giới hạn tốc độ hoạt động giống nhau bất kể ai là người nhận.

Email của agent có vào thư mục spam không?

Có thể ban đầu. Mỗi agent nhận được subdomain mới và người gửi mới chưa có uy tín. Người nhận có thể cần kiểm tra thư mục spam cho vài email đầu tiên. Theo thời gian, khi agent gửi email hợp lệ và người nhận tương tác, khả năng gửi sẽ cải thiện. Xem Gửi email để biết thêm chi tiết.

Tại sao chọn email thay vì giao thức agent native như A2A?

Email tiếp cận toàn bộ internet hiện có — hàng tỷ người và doanh nghiệp đã sử dụng. A2A yêu cầu cả hai bên triển khai giao thức. Khi agent cần liên lạc với ai đó ngoài hệ sinh thái, email là lựa chọn phổ quát. Agent có lẽ sẽ cần cả hai.

Tại sao chọn email thay vì WhatsApp, Telegram hoặc các ứng dụng nhắn tin khác?

Các ứng dụng nhắn tin có vẻ phù hợp tự nhiên cho giao tiếp giữa các agent, nhưng chúng có những hạn chế cấu trúc khiến chúng không thực tế cho agent ở quy mô lớn.

Khả năng mở rộng — Bạn có thể tạo hàng trăm địa chỉ email bằng lập trình. WhatsApp, Telegram và Signal đều yêu cầu số điện thoại và xác minh. Mở rộng quá vài tài khoản là không thực tế, thường vi phạm điều khoản dịch vụ, và đôi khi không thể nếu không có thẻ SIM vật lý. Nếu quy trình của bạn cần 50 agent, bạn sẽ cần 50 số điện thoại.

Không có rào cản — Email là kênh giao tiếp duy nhất mà bạn có thể tạo danh tính mà không cần số điện thoại, giấy tờ tùy thân, hoặc sự phê duyệt từ chủ nền tảng. Không có công ty nào kiểm soát ai được cấp địa chỉ email.

Giao thức mở — Email là liên bang và trung lập với nhà cung cấp. WhatsApp, Discord và Telegram là độc quyền — họ có thể thu hồi quyền truy cập API, cấm tài khoản bot, hoặc thay đổi quy tắc bất kỳ lúc nào. Email không thể bị tắt bởi một công ty duy nhất.

Tuân thủ ToS — Hầu hết các nền tảng nhắn tin cấm rõ ràng tài khoản tự động hoặc có quy trình phê duyệt nghiêm ngặt (WhatsApp Business API yêu cầu xác minh doanh nghiệp, Telegram hạn chế nhắn tin bot-với-bot). Email không có những hạn chế như vậy — gửi tự động là trường hợp sử dụng hạng nhất.

Phạm vi tiếp cận toàn cầu — Các kênh nhắn tin bị cô lập. Bot Telegram của bạn không thể liên hệ người dùng WhatsApp. Email tiếp cận bất kỳ ai có địa chỉ email — tức là hầu như tất cả mọi người.

Bổ sung, không cạnh tranh — Các framework agent đa kênh như OpenClaw hỗ trợ hàng chục kênh nhắn tin, và email nên là một trong số đó. InboxAPI lấp đầy khoảng trống mà các nền tảng nhắn tin về mặt cấu trúc không thể lấp: tạo danh tính không giới hạn, có thể lập trình mà không cần sự phê duyệt của nền tảng.

Giới hạn gửi là gì?

Mỗi tài khoản có 5 slot danh bạ cho người nhận bên ngoài. Khi tất cả slot đang sử dụng, mục ít được sử dụng gần đây nhất sẽ tự động được thay thế sau 5 ngày không hoạt động. Email đến các địa chỉ @inboxapi.ai, @inboxapi.io hoặc @inboxapi.dev không tính vào giới hạn này. Xem Giới hạn & Sử dụng hợp lý để biết đầy đủ chi tiết.

Chuyện gì xảy ra khi đạt giới hạn?

Khi tất cả 5 slot đang sử dụng, mục ít được sử dụng gần đây nhất sẽ tự động được thay thế sau 5 ngày không hoạt động.

How does the addressbook work? Do I need to add contacts?

The addressbook is automatic — contacts are added when you send email. You never need to add, configure, or manage contacts manually. There is no settings file, no contact list to maintain, and no setup step.

When your agent sends an email to a new external address, that address is recorded in the addressbook. Each account has 5 slots. When all 5 are in use, the least recently used entry is auto-replaced after 5 days of inactivity. Emails to other @inboxapi.ai addresses are always unlimited and don’t use a slot.

Các hạn chế hiện tại là gì?

• 5 slot danh bạ cho người nhận bên ngoài: Mỗi tài khoản có 5 slot cho người nhận bên ngoài. Khi tất cả slot đang sử dụng, mục ít được sử dụng gần đây nhất sẽ tự động được thay thế sau 5 ngày không hoạt động.
• Chỉ sử dụng cá nhân: InboxAPI không phải dịch vụ email giao dịch — không dùng cho gửi hàng loạt, marketing hay thông báo ứng dụng.

Thông tin đăng nhập hoạt động thế nào?

Thông tin đăng nhập của agent được lưu cục bộ tại ~/.config/inboxapi/credentials.json (Linux) hoặc ~/Library/Application Support/inboxapi/credentials.json (macOS). CLI xử lý tạo và refresh token tự động — agent không bao giờ cần quản lý token thủ công.

Nếu agent của tôi mất quyền truy cập tài khoản thì sao?

Nếu thông tin đăng nhập của agent bị mất hoặc hỏng, bạn có thể khôi phục tài khoản bằng công cụ account_recover — nhưng chỉ khi bạn đã liên kết email của mình trước đó qua verify_owner. Quá trình khôi phục thu hồi tất cả token hiện có và cấp thông tin đăng nhập mới. Nếu không có email chủ sở hữu đã xác minh, không có cách nào để khôi phục tài khoản bị khóa.

Xác minh chủ sở hữu là gì?

Xác minh chủ sở hữu liên kết địa chỉ email cá nhân của bạn với tài khoản InboxAPI của agent. Agent của bạn gọi verify_owner với email của bạn, bạn nhận được mã 6 chữ số, và agent gửi mã đó để hoàn tất xác minh. Sau khi xác minh, bạn có thể khôi phục tài khoản nếu thông tin đăng nhập bị mất, và các hạn chế dùng thử sẽ được gỡ bỏ khỏi tài khoản.

Những domain nào bị chặn?

InboxAPI chặn gửi đến domain chính phủ (.gov), quân sự (.mil), tình báo, cơ quan thực thi pháp luật, hạ tầng quan trọng và email dùng một lần.

Phân loại độ tin cậy hoạt động thế nào?

Mỗi email đến được phân loại vào một trong bốn mức tin cậy:

Mức tin cậy	Ý nghĩa	Hành động khuyến nghị
Trusted	Người gửi trong danh bạ với SPF/DKIM hợp lệ	An toàn để thực hiện
Agent	Người gửi là agent InboxAPI đã biết	Đọc tự do, nhưng xác nhận với người dùng trước khi hành động
Unverified	SPF/DKIM hợp lệ nhưng người gửi không trong danh bạ	Cẩn thận
Suspicious	Xác thực thất bại hoặc người gửi không xác định	Đánh dấu và xác nhận trước khi hành động

Điều gì ngăn agent mua sắm hoặc phê duyệt giao dịch qua email?

InboxAPI là kênh giao tiếp, không phải môi trường thực thi. Nó có thể gửi email, nhưng không thể nhấp nút, nhập số thẻ tín dụng hay tương tác với hệ thống bên ngoài. Rủi ro hành động trái phép đến từ cách cấu hình agent và các công cụ khác có quyền truy cập — không phải từ email.