Budget for requests, not just emails
A test that receives one email can make many API requests. Generating an address, repeatedly checking an empty inbox, reading message detail and deleting a test message are separate operations. Polling is often the largest variable. The number of delivered emails alone is therefore a poor estimate of the quota you need.
CleanTempMail's API page shows the available request packs and their current prices. Use the quota attached to your key and any daily limit shown in its usage response. A request pack is not an unlimited mailbox subscription. Check the current plans rather than relying on a price copied into an older tutorial.
A concrete upper-bound calculation
For a run that generates one address, makes at most 18 inbox polls, fetches one message body and performs one cleanup call, reserve up to 21 requests per run. A failed run may consume less, but budgeting for the allowed maximum keeps failures from unexpectedly exhausting the key.
| Operation | Maximum per run |
|---|---|
| Generate an address | 1 |
| Poll the inbox | 18 |
| Read matching message detail | 1 |
| Delete test message or clear test inbox | 1 |
| Total | 21 |
At 100 runs per day, that example reserves 2,100 requests. Adding 20% operational headroom gives 2,520 requests per day, or 75,600 over a 30-day planning window. This is arithmetic for a hypothetical workload, not a plan recommendation or a billing period. If the test only needs a subject assertion, omit the detail fetch. If it must fetch attachments, include those requests too.
Measure a small representative batch
- Record the key's usage before a controlled test batch, and avoid unrelated jobs sharing it while measuring.
- Log each test's attempt count and elapsed time, without message bodies or credentials.
- Record usage after the batch. Compare the difference with the expected generation, polling, detail and cleanup calls.
- Use typical and slow test runs separately. A normal run's average can hide a costly timeout case.
Use the quota checker to inspect remaining total and daily allowance. Empty inbox responses are still authenticated API calls. A server error after quota has been reserved can also consume a request; do not assume that every failed response is free. Rejections before quota reservation, such as an invalid key or an early rate limit, are different.
Control concurrency as well as total volume
Twenty jobs polling every five seconds produce roughly four polls per second when spread evenly, but twenty simultaneous polls if they all wake together. Generation and detail requests add to that burst. Start jobs gradually, add bounded jitter between jobs, and share a limiter across workers using the same key. Per-key and per-IP protections can both apply.
A larger request allowance does not imply a higher instantaneous request rate. Honor Retry-After on rate-limit responses. If the delay would exceed the test deadline, fail the test instead of ignoring the server's delay. See the retry decision table.
Reduce waste without weakening the test
- Use
summary=1while waiting; fetch the body only after matching sender, subject marker and timestamp. This saves transferred data, not polling quota. - Stop as soon as the intended message arrives. Keep one poll loop per test inbox.
- Set both a maximum attempt count and a total waiting budget. Do not let a CI retry silently multiply an unlimited inner loop.
- Use a separate fresh inbox for each run. Do not clear a shared inbox that another job is still using.
- Review measured latency before shortening the interval. More frequent polling cannot make the sending system deliver sooner.
Start from the tested Python and JavaScript helpers, then adjust the waiting budget to your own application's measured delivery behavior.