Chưa được xây dựng

Tự thử để phát hiện thì tệ hơn là được cho biết trước. Không điều nào sau đây tồn tại ở thời điểm hiện tại:

• —Một lần chuyển phát được thử tối đa năm lần: ngay khi sự kiện xảy ra, sau đó sau 1 phút, 5 phút, 25 phút và 2 giờ. Mọi lần thử đều được ghi lại và có thể đọc qua GET /webhooks/{id}/deliveries, mỗi lần mang attempt và maxAttempts. Việc thử lại dừng sớm khi phản hồi cho thấy lặp lại là vô ích: mọi mã khác 408, 425, 429 hoặc 5xx được coi là từ chối có chủ đích. Vẫn chưa có endpoint phát lại, nên một endpoint ngừng hoạt động lâu hơn khoảng thời gian đó sẽ có khoảng trống, và nhật ký chuyển phát là nơi bạn tìm ra nó.
• —Một thư bị trả lại vẫn hiển thị là sent qua GET /emails: báo cáo chuyển phát được đối chiếu với thư gốc và gắn nhãn trên luồng thư, nhưng không có gì ghi ngược lại vào hàng gửi, vốn có trạng thái không bao gồm bounced. Danh sách chặn gửi mà nó cập nhật là có thật: một hard bounce hoặc một khiếu nại sẽ đưa địa chỉ vào danh sách chặn gửi của không gian làm việc này và lần gửi tiếp theo đến địa chỉ đó sẽ bị từ chối. Chính bản ghi gửi là thứ không được cập nhật.
• —Không có bộ giới hạn tốc độ yêu cầu chung. Có hai mức trần được đếm và cả hai đều trả về 429: một không gian làm việc dùng hết hạn mức gửi hằng tháng mà gói của nó bao gồm sẽ nhận send_quota_exceeded cho mọi lần gửi tiếp theo cho đến ngày đầu tháng sau, và việc tạo hộp thư dùng một lần bị giới hạn ở sáu hộp mỗi giờ và ba mươi hộp mỗi ngày cho mỗi client với too_many_inboxes. Cả hai đều không kèm Retry-After. Việc thiếu bộ giới hạn tốc độ cho các thao tác đọc và ghi thông thường là một khoảng trống chứ không phải một cam kết, và sẽ được khắc phục.
• —Không có endpoint TẢI LÊN tệp đính kèm trên API. Tệp đính kèm nội tuyến dùng base64 và bị giới hạn 5 MB cho toàn bộ thư. Tệp lớn hơn được gửi dưới dạng { fileId }, chỉ đến một tệp đã có trong không gian làm việc, và được chuyển dưới dạng liên kết tải xuống. Việc đọc tệp đính kèm từ thư nhận được thì vẫn hoạt động.