LINE replyToken hết hạn? Xử lý phản hồi chậm mà không gửi trùng
replyToken của LINE Messaging API chỉ dùng được một lần và phải được dùng trong vòng một phút sau khi nhận webhook. Sau khoảng thời gian đó, LINE không bảo đảm token còn hoạt động. Nếu AI tạo câu trả lời chậm hoặc tác vụ phải chờ trong hàng đợi, đừng liên tục gửi lại token hay tự động chuyển sang push ngay khi yêu cầu hết thời gian chờ. Trước tiên, hãy phân biệt token chưa dùng với phản hồi đã gửi nhưng chưa rõ kết quả.
Điểm chính
- Reply token là cơ hội phản hồi ngắn hạn, không phải ID người nhận hay thông tin xác thực dùng nhiều lần.
- Webhook được gửi lại không tạo ra một cơ hội phản hồi độc lập thứ hai.
- Timeout nghĩa là chưa rõ kết quả, không chứng minh rằng tin nhắn chưa được gửi.
- Push là thao tác riêng với điều kiện người nhận và cách tính số tin nhắn riêng, không phải gia hạn token.
Quy định thực tế của LINE về reply token
Tài liệu tham chiếu Messaging API định nghĩa POST /v2/bot/message/reply, sử dụng replyToken của sự kiện và mảng messages. Token chỉ dùng một lần và nên được dùng càng sớm càng tốt. LINE cũng lưu ý thời hạn có thể thay đổi, vì vậy không nên thiết kế worker đợi đến giây cuối cùng mới gửi.
Ngay cả câu trả lời tức thì như “Chúng tôi đang kiểm tra” cũng tiêu thụ token. Câu trả lời hoàn chỉnh sau đó không thể dùng lại token ấy. Hướng dẫn gửi tin nhắn cho phép tối đa năm đối tượng tin nhắn trong một yêu cầu reply, chứ không phải năm yêu cầu riêng với cùng token.
| Giá trị | Mục đích | Không thay thế cho |
|---|---|---|
| Channel access token | Xác thực yêu cầu API của channel | Reply token mới |
replyToken | Trả lời hành động tạo ra sự kiện | Địa chỉ người dùng lâu dài |
| Định danh người nhận | Chỉ định đích push đủ điều kiện | Quyền sử dụng lại thao tác reply |
Nếu đang xử lý thông báo LINE MINI App, hãy đọc so sánh service messages và Messaging API trước. Service notification token thuộc một hợp đồng API khác.
Chẩn đoán trước khi chọn cách gửi thay thế
Bảng sau là các kiểm tra được đề xuất cho ứng dụng, không phải mã lỗi mới của LINE.
| Bằng chứng | Ranh giới cần kiểm tra | Bước tiếp theo an toàn |
|---|---|---|
| Worker bắt đầu rất lâu sau khi nhận webhook | Hàng đợi chậm hoặc tạo nội dung lâu | Không dựa vào token cũ; đánh giá việc gửi muộn riêng |
| Worker khác đã nhận kết quả reply thành công | Token một lần đã bị sử dụng | Dừng tác vụ trùng |
| HTTP timeout sau khi phát yêu cầu | Chưa rõ yêu cầu được chấp nhận hay chưa | Giữ trạng thái chưa rõ, không push ngay cùng câu trả lời |
| Webhook giống hệt đến lần nữa | Nhận sự kiện trùng | Tra trạng thái xử lý và gửi của sự kiện gốc |
| Sự kiện vừa nhận cũng không reply được | Nội dung yêu cầu, thông tin xác thực channel, chọn token hoặc lỗi API khác | Kiểm tra phản hồi thực tế, không quy mọi lỗi thành hết hạn |
Ghi lại thời điểm nhận webhook, bắt đầu worker, phát yêu cầu, HTTP status và lần gửi thành công trước đó nếu có. Không ghi token hoặc header xác thực vào log thông thường. Chỉ giữ dữ liệu token trong nơi được bảo vệ trong thời gian cần cho thao tác ngắn hạn.
Một lỗi đơn lẻ không cho biết worker khác đã trả lời hay chưa. Cấp lại channel access token cũng không làm reply token đã dùng trở nên hợp lệ lần nữa.
Gửi lại webhook không phải dịch vụ làm mới token
Hướng dẫn nhận tin nhắn của LINE cho biết webhook gửi lại giữ nguyên ID sự kiện và reply token; deliveryContext.isRedelivery thay đổi. Ứng dụng nên dùng định danh channel cùng webhookEventId làm khóa phát hiện trùng.
Tài liệu tham chiếu cho phép dùng token trong vòng một phút sau khi nhận webhook được gửi lại, nhưng có ngoại lệ: không thể dùng nếu token đã được sử dụng hoặc đã qua hai mươi phút kể từ lúc sự kiện xảy ra. Đây là cơ hội phục hồi có giới hạn, không phải cửa sổ hẹn giờ trả lời hay lý do để cố tình từ chối webhook.
Lưu bền vững sự kiện rồi xác nhận tiếp nhận độc lập với công việc tốn thời gian. Webhook trùng phải tìm tác vụ hiện có, thay vì khởi chạy thêm một lần tạo câu trả lời AI và gửi mới. Cũng cần lưu trạng thái gửi: chỉ khử trùng ở đầu vào không bảo vệ tác vụ được chạy lại sau khi worker gặp sự cố.
Chọn đường phản hồi trước khi bắt đầu tác vụ chậm
Với câu trả lời nhanh, giao sự kiện cho một worker và reply sớm. Với công việc có thể vượt thời gian dùng token, hãy quyết định từ đầu: gửi xác nhận đã nhận trước rồi gửi kết quả sau, hay chỉ gửi kết quả khi hoàn thành.
Thiết kế ứng dụng được đề xuất:
- Chỉ nhận quyền xử lý sự kiện một lần. Gắn channel và
webhookEventIdvới một thao tác nghiệp vụ. Bản ghi duy nhất hoặc cơ chế nhận việc trong giao dịch ngăn hai worker tự gửi độc lập. - Lưu quyết định gửi. Phân biệt reply ngay với push sau. Tin xác nhận đã nhận là một phản hồi hoàn chỉnh, không phải giữ chỗ token.
- Ghi nhận đúng kết quả. Tách trạng thái nội bộ thành chưa thử, đã được chấp nhận, bị từ chối và chưa rõ kết quả. Đây là nhãn của ứng dụng, không phải trường phản hồi LINE. Tiến trình dừng sau khi phát yêu cầu cũng có thể để lại kết quả chưa rõ.
- Kiểm tra trước khi gửi muộn. Xác nhận câu trả lời còn phù hợp, nhân viên chưa trả lời và người nhận đáp ứng điều kiện push hiện tại của LINE. Nếu kết quả gửi trước đó chưa rõ, phải có quyết định rõ ràng trước khi tiếp tục.
- Lưu push như thao tác mới. Dùng yêu cầu và biện pháp bảo vệ riêng. Push không thay đổi kết quả reply trước đó.
Tài liệu giá của LINE phân biệt cách đếm: reply không được tính vào số tin nhắn của gói đăng ký, còn push thì có. Hãy kiểm tra gói áp dụng, không mặc định cách gửi thay thế có cùng cách tính.
Với retry push được hỗ trợ, xem hướng dẫn X-Line-Retry-Key. Tài liệu retry chính thức liệt kê push, multicast, narrowcast và broadcast, không có reply. Thêm header này vào reply không gia hạn token và không khử trùng push sau đó với reply trước đó.
Giữ riêng hợp đồng phản hồi của UnifyPort
Giao diện không chính thức của UnifyPort là đường kết nối tài khoản nhắn tin riêng, không phải cơ chế sửa reply token của LINE Official Account. Tài liệu gửi văn bản dùng POST /v1/messages với account_id, to và message. Ma trận hỗ trợ nền tảng mô tả gửi văn bản LINE, nhưng thao tác trả lời trích dẫn bằng token hiện chỉ dành cho WhatsApp.
Đừng đưa replyToken của LINE vào reply_to.reply_token của UnifyPort. Tên gần giống nhau không có nghĩa là dùng thay thế được. Với câu trả lời thông thường cho sự kiện chuẩn hóa đã lưu, hãy dùng định danh tài khoản và cuộc hội thoại theo tài liệu, rồi kiểm tra kết quả gửi thực tế. Điều này không ngụ ý khả năng khử trùng xuyên API hay phục hồi token. Nhóm vận hành cả WhatsApp, Zalo và LINE cũng nên kiểm tra khả năng từng nền tảng thay vì suy từ tên trường chung.
Nếu người gửi bắt buộc phải là LINE Official Account, hãy tiếp tục dùng Messaging API chính thức. Thay đổi danh tính tích hợp không phải lựa chọn tự động an toàn khi kết quả gửi chính thức còn chưa rõ.
Câu hỏi thường gặp
Có thể làm mới LINE reply token đã hết hạn không?
Không nên xử lý nó như access token có thể làm mới. Sự kiện mới đủ điều kiện mang theo cơ hội trả lời riêng; webhook gửi lại tuân theo các giới hạn trên. Cả hai đều không cho phép thử gửi cùng câu trả lời nghiệp vụ vô hạn.
Có thể xác nhận đã nhận rồi dùng cùng token gửi kết quả cuối không?
Không. Reply đầu tiên được chấp nhận sẽ tiêu thụ token một lần. Lên kế hoạch riêng cho câu trả lời sau đó, kiểm tra điều kiện người nhận push và số tin nhắn được tính.
Mọi timeout của reply có nên kích hoạt push không?
Không. Reply có thể đã được chấp nhận. Push tự động có thể tạo tin trùng. Giữ trạng thái chưa rõ kết quả và đặt chính sách gửi thay thế có chủ đích.
Bước tiếp theo và nguồn
Đối chiếu một luồng phản hồi chậm với tài liệu LINE Messaging API. Dùng mô phỏng cục bộ để kiểm tra giao lại trùng, hai worker tranh việc, xác nhận đã nhận rồi trả lời muộn và mất HTTP response. Đây là các kiểm thử đề xuất, không phải kết quả vận hành thực tế. Với đường tài khoản kết nối riêng, bắt đầu từ hợp đồng gửi văn bản UnifyPort.
Tài liệu chính thức được kiểm tra ngày 2026-10-04:
Biến tích hợp nhắn tin thành một pipeline sản phẩm ổn định.
Bắt đầu bằng cách gửi qua một API, rồi đưa mọi tin nhắn inbound trở lại hệ thống kinh doanh bằng sự kiện chuẩn.