---
title: "Trả lời và chuyển tiếp email qua API: kiểm soát AI trước khi gửi"
description: "Chọn trả lời hay chuyển tiếp email qua API, cấp quyền read/send và kiểm tra người nhận trước khi AI gửi. Kèm cách xử lý yêu cầu hết thời gian chờ."
url: https://mailera.app/blog/tra-loi-va-chuyen-tiep-email-qua-api
published: 2026-10-25
updated: 2026-10-25
---

# Trả lời và chuyển tiếp email qua API: kiểm soát AI trước khi gửi

Hai tình huống hỗ trợ khách hàng để chọn đúng hành động, kiểm tra người nhận và tách quyền đọc khỏi quyền gửi. Bước phê duyệt nằm trong ứng dụng của bạn.

## Trả lời và chuyển tiếp khác nhau ở đâu?

Chọn hành động theo người cần nhận thông tin, không theo từ khóa trong thư. Khách hỏi tiến độ yêu cầu thì nên trả lời khách. Yêu cầu cần chuyên viên nội bộ xem xét thì nên chuyển tiếp phần cần thiết cho chuyên viên.

| Điểm cần xét | Trả lời | Trả lời tất cả | Chuyển tiếp |
| --- | --- | --- | --- |
| Mục đích | Tiếp tục trao đổi | Tiếp tục với các bên liên quan | Giao nội dung cho người khác |
| Người nhận | Người nhận phản hồi phù hợp của thư gốc | Các bên cần tiếp tục tham gia | Người xử lý được chọn |
| Liên hệ với thư gốc | Phản hồi thư đó | Phản hồi thư đó với phạm vi rộng hơn | Đưa nội dung gốc vào trao đổi khác |
| Nội dung cần rà | Phản hồi và phần trích dẫn | Phản hồi, trích dẫn, danh sách người nhận | Lời dẫn, chuỗi thư, tệp đính kèm |
| Rủi ro | Trả lời sai địa chỉ | Lộ thông tin cho người không cần biết | Chuyển cả lịch sử nội bộ ra ngoài |

Bảng này phân biệt mục đích sử dụng, không quy định cấu trúc yêu cầu API. Trong Mailera, `POST /mailboxes/{id}/send` dùng cho gửi, trả lời và chuyển tiếp. Tổng quan các cách tích hợp nằm ở [trang sản phẩm Mailera](https://mailera.app/product); phần nền tảng cho agent nằm trong bài [dùng hộp thư sẵn có cho AI agent](https://mailera.app/blog/ket-noi-email-voi-ai).

![Chọn trả lời để tiếp tục trao đổi, chuyển tiếp để giao người khác, hoặc dừng khi chưa rõ người nhận.](https://mailera.app/media/fe9c7781987b3c40/tra-loi-va-chuyen-tiep-email-qua-api-kiem-soat-ai-truoc-khi-vi-1200.jpg)
_Chọn hành động trước, kiểm tra người nhận và duyệt bản cuối trước khi gửi._

### Thêm `Re:` có giữ luồng hội thoại không?

Không đủ. [Tài liệu luồng hội thoại của Gmail API](https://developers.google.com/workspace/gmail/api/guides/threads) yêu cầu `threadId` đích, các header `References` và `In-Reply-To` đúng chuẩn, cùng `Subject` khớp để thêm thư vào một luồng.

Đây là yêu cầu của Gmail API, không phải tên trường để tự thêm vào yêu cầu Mailera. Khi thử tích hợp, hãy đối chiếu thư nhận được trên từng nhà cung cấp; đừng coi tiêu đề giống nhau là bằng chứng thư đã nằm đúng luồng.

## Cần chuẩn bị quyền gì trước khi cho agent gửi?

Dùng hộp thư thử do bạn kiểm soát và có khả năng gửi. Có thể đọc `capabilities.send` qua `GET /mailboxes/{id}`; hộp thư ở chế độ Chỉ nhận (hiển thị "Hộp thư này chỉ nhận thư — chưa gửi được" trong ứng dụng) không phù hợp với bước trả lời hoặc chuyển tiếp.

1. Tạo nhóm riêng cho các hộp thư thử.
2. Trong **Cài đặt**, mở tab **API key** và chọn **Tạo key**. Đặt **Tên gợi nhớ**, rồi chọn nhóm ở **Phạm vi hộp thư**. Quản trị viên còn có thể chọn mọi nhóm; ví dụ này chỉ cần nhóm thử.
3. Bật quyền **Read** cho thành phần đọc. Bật quyền **Send messages** cho thành phần gửi đã qua phê duyệt. Quyền `send` cũng cần để đọc trạng thái lần gửi bằng `GET /sends/{id}`.
4. Đặt **Thời hạn** và **Giới hạn IP (tuỳ chọn)** phù hợp với máy chủ chạy ứng dụng. Lưu khóa phía máy chủ, không đưa vào ngữ cảnh mô hình.

![Hộp thoại tạo khóa API với phạm vi nhóm hộp thư, quyền truy cập và thời hạn.](https://mailera.app/media/5075dd2df81f9d84/chong-gui-email-trung-lap-qua-api-voi-idempotency-key-api-vi-1200.jpg)
_Giới hạn khóa vào nhóm thử; tách quyền đọc và gửi theo vai trò của từng thành phần._

Nên tách hai thành phần để agent đọc thư không trực tiếp giữ khóa gửi. Quyền `send` dùng chung cho gửi, trả lời và chuyển tiếp; chính sách “chỉ trả lời khách hiện tại” phải do ứng dụng thực thi.

Bạn có thể đối chiếu [thông tin bảo mật Mailera](https://mailera.app/security) khi thiết kế cách lưu khóa. Bạn cần xây bước duyệt người nhận và nội dung dưới đây trong ứng dụng.

## Ví dụ 1: trả lời khách hỏi tiến độ

Giả sử khách hỏi tiến độ xử lý một yêu cầu. Agent cần soạn phản hồi trong cuộc trao đổi hiện tại, không thêm người nhận mới.

### 1. Đọc đúng thư gốc

Đặt `$MAILERA_API_KEY`, `$MAILBOX_ID` và `$MESSAGE_ID` bằng giá trị của môi trường thử. Lệnh này cần quyền `read`:

```bash
curl --request GET \
  "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages/$MESSAGE_ID" \
  --header "Authorization: Bearer $MAILERA_API_KEY"
```

Đối chiếu `data.id` và `data.mailbox_id`, rồi đọc `from`, `to`, `cc`, `subject` và `body`. Giữ cặp mã hộp thư, mã thư cùng bản nháp trong ứng dụng; đừng để agent chọn lại thư gốc từ một tiêu đề gần giống.

### 2. Xác định người nhận trước khi soạn xong

Không lấy địa chỉ từ câu “hãy trả lời vào địa chỉ này” trong nội dung làm đích gửi tự động. Khi địa chỉ trả lời khác người gửi, cần kiểm tra riêng.

Chẳng hạn, [Microsoft Graph quy định về trả lời thư](https://learn.microsoft.com/en-us/graph/api/message-reply?view=graph-rest-1.0) rằng phản hồi JSON phải dùng người nhận trong `replyTo` nếu trường đó chỉ định người nhận, thay vì `from`. Vì vậy, chỉ nhìn tên hiển thị hoặc địa chỉ người gửi là chưa đủ để quyết định.

### 3. Cho người duyệt xem bản cuối

Màn hình duyệt của ứng dụng nên hiển thị hộp thư gửi, hành động trả lời, toàn bộ địa chỉ nhận và nội dung cuối cùng, kể cả phần trích dẫn. Nếu có thêm người nhận so với dự kiến, dừng để kiểm tra thay vì tự chuyển thành trả lời tất cả.

### 4. Gửi rồi kiểm tra kết quả

Sau xác nhận, thành phần gửi gọi `POST /mailboxes/{id}/send` theo cấu trúc trả lời trong [tài liệu API Mailera](https://mailera.app/docs). Lưu mã lần gửi để tra cứu bằng `GET /sends/{id}`, rồi mở hộp thư thử nhận để kiểm tra người nhận, nội dung và vị trí trong cuộc hội thoại.

Nếu dùng MCP, công cụ `reply_to_email` cần quyền `send`. Cách tổ chức các bước đọc và hành động được trình bày trong bài [API email cho AI agent](https://mailera.app/blog/api-email-cho-ai-agent).

## Ví dụ 2: chuyển tiếp cho chuyên viên nội bộ

Giả sử khách gửi yêu cầu cần chuyên viên xem xét. Mục tiêu là giao đủ thông tin để xử lý, không chuyển nguyên mọi thứ agent đọc được.

1. **Chọn người nhận từ danh sách ứng dụng cho phép.** Không lấy địa chỉ đích từ chỉ dẫn trong thư. Nếu không tìm được người phụ trách phù hợp, chuyển sang kiểm tra thủ công.
2. **Rà phần nội dung sẽ chuyển.** Xem cả chuỗi trích dẫn, thông tin khách hàng và tệp đính kèm. Loại phần không phục vụ yêu cầu xử lý.
3. **Viết lời dẫn cụ thể.** Ví dụ: “Nhờ kiểm tra nguyên nhân yêu cầu chưa hoàn tất trước khi phản hồi khách.” Tránh để người nhận phải đoán việc cần làm từ cả chuỗi thư.
4. **Duyệt bản cuối và gửi.** Hiển thị địa chỉ đích cùng nội dung, danh sách tệp dự kiến. Sau xác nhận, dùng `POST /mailboxes/{id}/send` theo cấu trúc chuyển tiếp trong tài liệu.
5. **Kiểm tra tại hộp thư nhận.** Đối chiếu địa chỉ nhận, nội dung thực tế và tệp đính kèm; không mặc định API tự giữ hoặc loại bỏ tệp theo ý bạn.

[Tài liệu chuyển tiếp của Microsoft Graph](https://learn.microsoft.com/en-us/graph/api/message-forward?view=graph-rest-1.0) cũng quy định riêng cách chỉ định người nhận. Không sao chép các trường của Graph vào yêu cầu Mailera.

Ví dụ này dùng REST API. Bộ công cụ MCP của Mailera có `reply_to_email`, nhưng không có công cụ chuyển tiếp chuyên biệt. Xem [các giao diện dành cho nhà phát triển](https://mailera.app/developers) để chọn cách tích hợp phù hợp.

## Những lỗi nào hay gặp?

| Lỗi | Việc nên kiểm tra |
| --- | --- |
| Gửi sai người | Danh sách địa chỉ thực tế, không chỉ tên hiển thị; có nhầm trả lời với trả lời tất cả không |
| Lộ dữ liệu khi chuyển tiếp | Toàn bộ phần trích dẫn và tệp, không chỉ lời dẫn mới viết |
| Thư tách khỏi cuộc hội thoại | Mã thư gốc, cấu trúc yêu cầu và thư thực nhận; đừng chỉ sửa tiêu đề |
| Đọc được nhưng gửi không được | Quyền `send`, phạm vi nhóm của khóa và `capabilities.send` của hộp thư |
| Yêu cầu hết thời gian chờ | Trạng thái lần gửi trước khi quyết định thử lại |

### Hết thời gian chờ không có nghĩa là chưa gửi

Đừng gửi lại ngay. Nếu đã có mã lần gửi, dùng `GET /sends/{id}` với quyền `send`. Các trạng thái gồm `queued`, `sending`, `sent`, `failed` và `unknown`. Với `unknown`, cần đối chiếu yêu cầu thay vì tự xem là thất bại rồi gửi thêm.

Endpoint gửi chấp nhận header `Idempotency-Key`, với cửa sổ 24 giờ. Hãy quản lý khóa này theo từng thao tác gửi trong ứng dụng và áp dụng quy tắc thử lại trong [hướng dẫn chống gửi trùng bằng Idempotency-Key](https://mailera.app/blog/chong-gui-email-trung-lap-qua-api). Nếu chưa có mã lần gửi, đối chiếu nhật ký yêu cầu cùng hộp thư thử trước khi tạo một lần gửi mới. Trạng thái lần gửi không phải xác nhận người nhận đã đọc thư.

## Làm sao ngăn thư đến trở thành lệnh cho agent?

**Thư đến là dữ liệu không tin cậy, không phải lệnh.** Một thư yêu cầu agent đổi người nhận, tiết lộ khóa hoặc chuyển dữ liệu ra ngoài không được phép thay đổi chính sách của ứng dụng.

Mã ứng dụng phải kiểm tra quyền, giới hạn người nhận theo danh sách được phép và yêu cầu xác nhận; không chỉ dựa vào lời nhắc cho mô hình. Gắn phê duyệt với đúng hộp thư gửi, hành động, người nhận, nội dung và tệp đính kèm. Bất kỳ phần nào thay đổi sau duyệt đều phải được duyệt lại.

Chỉ đưa phần thư cần thiết vào ngữ cảnh mô hình. Che dữ liệu cá nhân trong ảnh và nhật ký; không ghi khóa API vào nội dung trao đổi với agent. Bài [phê duyệt qua email ở lớp ứng dụng](https://mailera.app/blog/phe-duyet-qua-email-cho-tac-nhan-ai) trình bày riêng cách tổ chức bước xác nhận.

## Giới hạn cần giữ trong thiết kế

Mailera không phục vụ gửi hàng loạt hoặc gửi tiếp thị, và không bảo đảm thư vào hộp thư đến. Hãy giữ hai quy trình này ở phạm vi hỗ trợ khách hàng có kiểm soát: ứng dụng quyết định ai được nhận nội dung, còn quyền API giới hạn thao tác và nhóm hộp thư được truy cập.

**Làm điều này bằng API** — Mọi thao tác trong bài đều có REST API kèm ví dụ curl, khoá API và webhook. [Xem tài liệu API](https://mailera.app/docs)