아직 만들지 않은 것

해 보고 알게 되는 것보다 미리 듣는 편이 낫습니다. 아래 중 오늘 존재하는 것은 없습니다:

• —전달은 최대 다섯 번 시도합니다. 즉시, 그리고 1분, 5분, 25분, 2시간 뒤입니다. 모든 시도가 기록되며 GET /webhooks/{id}/deliveries로 읽을 수 있고, 각각 attempt와 maxAttempts를 담습니다. 반복이 무의미하다는 응답이 오면 재시도는 일찍 멈춥니다. 408, 425, 429나 5xx가 아닌 것은 모두 의도적인 거절로 봅니다. 아직 재전송 엔드포인트는 없으므로, 그 시간 창보다 오래 내려가 있던 엔드포인트에는 구멍이 생기고, 그 구멍은 전달 로그에서 찾습니다.
• —반송된 메시지도 GET /emails에서는 여전히 sent로 읽힙니다. 전달 보고서는 원본과 매칭되어 스레드에 표시되지만, 발송 행에는 아무것도 되쓰이지 않으며 그 status에는 반송 상태가 없습니다. 그것이 만들어내는 억제는 실재합니다. 하드 바운스나 신고가 들어오면 해당 주소가 이 워크스페이스의 억제 목록에 오르고 다음 발송은 거부됩니다. 배우지 못하는 것은 발송 기록 쪽입니다.
• —일반적인 요청 레이트 리미터는 없습니다. 카운트 기반 상한이 둘 있고 둘 다 429로 답합니다. 플랜에 포함된 월 발송 허용량을 다 쓴 워크스페이스는 다음 달 1일까지 모든 추가 발송에서 send_quota_exceeded를 받고, 일회용 받은편지함 발급은 클라이언트당 시간당 6개, 하루 30개로 제한되며 too_many_inboxes를 받습니다. 둘 다 Retry-After를 담지 않습니다. 일반적인 읽기와 쓰기 빈도에 대한 리미터는 약속이 아니라 부재이며, 바로잡을 예정입니다.
• —API에는 첨부파일 업로드 엔드포인트가 없습니다. 인라인 첨부는 base64이며 메시지 전체에서 5 MB로 제한됩니다. 더 큰 파일은 워크스페이스에 이미 있는 파일을 가리키는 { fileId }로 보내며 다운로드 링크로 전달됩니다. 받은 메일에서 첨부를 읽는 것은 동작합니다.