API

메시지 조회

본문이 포함된 메시지 하나입니다. 조회하는 행위가 읽음 표시를 남깁니다.

GETapi.openemail.uk/temp-mail/inboxes/{id}/messages/{messageId}

본인 키로 워크스페이스에 실제 호출을 실행합니다.

GET /temp-mail/inboxes/{id}/messages/{messageId}

본문이 포함된 메시지 하나입니다. 조회하는 행위가 읽음 표시를 남깁니다.

받은편지함 토큰

shell

export OE=https://api.openemail.ukexport INBOX="Authorization: Bearer oe_inbox_kQ8v…"

아래의 모든 호출은 POST /temp-mail/inboxes가 반환한 토큰을 API 키와 동일한 Authorization: Bearer 헤더에 담아 전달합니다. 주소 자체는 아무것도 인가하지 않으며, 이 분리는 형식적인 절차가 아니라 기능의 핵심입니다. 일회용 주소는 발급되는 순간 거리를 두고 대하려는 상대에게 건네지기 때문입니다.

경로의 id는 토큰이 가리키는 것과 같은 받은편지함을 가리켜야 합니다. 토큰만으로도 하나가 특정되므로 이는 이중 안전장치이지만, 덕분에 두 받은편지함을 혼동한 호출자는 엉뚱한 메일을 조용히 읽는 대신 404를 받습니다.

예시

행을 먼저 가져오되 받은편지함 범위로 한정하고, 그다음에 본문을 읽습니다. 호출자가 준 id로 곧장 스토리지에 접근하면 메시지 id를 가진 누구나 아무 받은편지함이나 읽을 수 있게 되는데, 스토리지 키는 권한이 아니기 때문입니다.

curl

curl "$OE/temp-mail/inboxes/tinb_9c2f41ab7d3e4c118a0f5d72/messages/tmail_4b81c07d2fa9418e93c6a13f" \  -H "$INBOX"

응답

{  "object": "temp_message",  "id": "tmail_4b81c07d2fa9418e93c6a13f",  "from": { "name": "Acme", "email": "[email protected]" },  "to": "[email protected]",  "subject": "Confirm your email",  "snippet": "Your code is 481923…",  "spam": false,  "seen": true,  "attachmentCount": 1,  "sizeBytes": 8241,  "receivedAt": "2026-09-01T10:31:04.000Z",  "message": { "decodedBody": "<p>Your code is 481923</p>", "…": "…" },  "truncated": false}

message.decodedBody를 렌더링하세요. 로컬에서 수신 처리된 메시지에서는 body와 processedHtml이 빈 문자열이며, 일회용 받은편지함에 도달할 수 있는 메시지는 전부 그렇습니다. 그 둘 중 하나를 읽고 아무것도 없다고 판단하는 것이 바로 이 안내가 막으려는 실수입니다.

message는 실제 메일함이 저장하는 것과 동일한 객체를 가공 없이 그대로 내보낸 것입니다. 이 형태가 곧 저장 스키마이며, 여기에 필드 목록을 손으로 적어 두면 금방 낡아 버리는 두 번째 설명이 될 뿐입니다. 또한 공격자가 제공한 HTML이므로 자신의 오리진 바깥에서 렌더링하세요.

truncated는 본문이 2 MB에서 잘렸다는 뜻입니다. 그 외에는 메시지가 온전하며 누락된 것은 없습니다.

저장된 본문이 이미 정리된 행은 세 단계 뒤 파싱에서 실패하는 대신, "해당 메시지는 이미 삭제되었습니다"라는 404를 응답합니다.