Receiving API access is temporarily paused.
New API keys and programmatic message reads are unavailable during the pause. The website inbox remains available for manual receiving.
Current status
Paused: key creation, key management and API message reads are unavailable.
This page does not promise a restart date. Existing integrations cannot bypass the pause.
Supported alternative
Create or reopen an inbox through the main website and read messages in the visible inbox interface.
The service remains receive-only. It does not send email, provide SMS or guarantee acceptance by third-party websites.
Open the website inboxQuick start: connect, create, read
Reference only while paused: The request format below is retained for existing developers, but the endpoint currently returns a paused-service response.
Connect your mailbox
Use its email and saved password, or connect the homepage inbox from this tab. This is mailbox access, not access to every inbox in your account.
Choose the least access needed
Select headers only for message listings. Enable full content only if your application needs to read message bodies. Copy your new key once and store it securely.
Make a server-side request
Send the key in the Authorization header. Never put it in a URL, public repository or browser-delivered JavaScript.
curl 'https://tempmail.cloud/api/v1/messages?limit=20' \ -H 'Authorization: Bearer YOUR_API_KEY'
Replace YOUR_API_KEY with your private key. Do not paste a real key into screenshots or support messages.
Available endpoints
GET /api/v1/messages
List messages for the connected mailbox. The default page size is 20; limit accepts 1–50. Pass the returned nextCursor as before to request another page.
GET /api/v1/messages/{id}
Read a message from the same mailbox. Requires full-content scope. A headers-only key cannot read its body.
This is a receiving API. It does not send email or grant access to other mailboxes.
Access limits & key safety
- Up to five active keys per mailbox.
- Keys expire after 30 days; timed inbox expiry may end access sooner.
- Maximum 60 requests per minute per key. Back off when you receive HTTP 429.
- Revoke a key here if it is exposed or no longer needed.
- Keep keys in server-side secret storage and avoid logging Authorization headers.
Poll conservatively rather than sending requests in a tight loop. Access is limited to the mailbox that issued the key. Do not use multiple keys to evade rate limits.
Handle errors without repeated retries
| Status | What to check |
|---|---|
| 400 | Check the page size and pagination cursor. |
| 401 | The key may be invalid, expired or revoked, or mailbox access may have expired. Check credentials before retrying. |
| 403 | The key does not have permission to read message content. Use the correct scope. |
| 404 | The endpoint or requested message is unavailable to this mailbox. |
| 405 | The receiving endpoints support GET requests only. |
| 429 | Pause requests and respect the Retry-After response header. |
API questions
Can an API key read another user’s inbox?
No. Each key is tied to one mailbox, and message access is checked against that mailbox. Treat the key as a password for that scope.
Can I use this API to send email?
No. These endpoints are receive-only. They provide message listings and, with the appropriate scope, message content.
What should I do if a key is leaked?
Revoke it in the key manager, create a replacement if needed, and update your application’s secret storage. Remove it from logs and public code as well.
Does a key keep a ten-minute inbox alive?
No. The mailbox expiry takes priority over the key’s lifetime. Use an appropriate reusable inbox for integrations that need longer access.