How InboxPolicy's Free 72-Hour Re-Verification Cache Works
By Aria Pramesi, founder of InboxPolicy · Updated July 4, 2026
InboxPolicy caches every fresh verification for 72 hours. An eligible re-check of the same normalized address and strictness inside that window with force_refresh: false returns from_cache instead of running SMTP checks again, and it costs 0 credits. After 72 hours the cache expires and the next check runs fresh at the normal $0.01 per-call rate.
What triggers a cache hit?
InboxPolicy caches every fresh verification result for 72 hours. The cache key includes the normalized email address and strictness. Submit the same normalized address with the same strictness inside the 72-hour window and leave force_refresh false and the API returns from_cache in the response instead of re-running SMTP checks, and the call bills 0 credits.
What comes back is the original decision, unchanged: the action, the confidence score, and the normalized signals, just flagged as served from cache rather than freshly checked.
Why does this matter for agents re-validating lists before every send?
Agents that verify a list right before a send often hit the same address more than once in a short span, a follow-up firing hours after the first touch, a queue re-checked before each batch, a retry after a temporary SMTP failure.
- Re-verify a list before every send without paying per check each time
- Refresh a send queue at 0 marginal cost only when each lookup matches an eligible cached normalized address and strictness and does not force refresh
- Only pay again once an address has aged past the cache window
How does this compare with other providers?
InboxPolicy is priced at $0.01 per call via x402, or from prepaid credit packs starting at $3.16 per 1,000 (Growth tier). None of that pricing includes a free re-check window beyond the 72-hour cache described here, and there is no separate free plan.
No comparable free re-verification window was found in the reviewed competitor pricing materials. Confirm each provider's repeat-billing terms directly.
What else can cost 0 credits at InboxPolicy?
- Malformed-email rejection: invalid syntax is rejected before any SMTP check runs, 0 credits.
- eligible cache hits for the same normalized address and strictness within 72 hours when force_refresh is false:
from_cacheresponses, 0 credits.
For API-key calls, the API also replays the same route, key, and payload while the idempotency record remains valid (24 hours by default). Keyless x402 calls do not use that wrapper; after an indeterminate settlement, do not submit a second payment. There is no free tier. The $0.01 per-call x402 price is the trial by design because free tiers attract list-cleaning abuse.
What happens once the 72-hour window expires?
Once 72 hours pass, the cached result expires. The next verification of that address runs a full fresh check, syntax, MX, and live SMTP, and bills at the standard rate: $0.01 per call via x402, or the applicable credit-pack rate ($5.00/1k Starter, $3.80/1k Builder, $3.16/1k Growth).
| Tool | Entry price | Free tier | Free re-verification window |
|---|---|---|---|
| InboxPolicy | $0.01 per call (x402), credit packs from $3.16/1k | None, pay-per-call is the trial | 72 hours, from_cache, 0 credits |
| ZeroBounce | ~$9.90/1k sub | 100/month | Not documented |
| Kickbox | ~$10.00/1k | One-time free credits | Not documented |
| MillionVerifier | $3.90/1k entry (down to $0.45/1k at 1M volume) | Available | Not documented |
Frequently asked questions
How long does InboxPolicy cache a verification result?
72 hours from the original fresh verification. An eligible re-check of the same normalized address and strictness inside that window with force_refresh false returns from_cache in the response and costs 0 credits. Once 72 hours pass, the cache expires and the next check runs a full fresh verification at the standard rate.
Does a cache hit cost credits or trigger a charge?
An eligible cache hit for the same normalized address and strictness within 72 hours, when force_refresh is false, returns from_cache and bills 0 credits. Otherwise the request runs a fresh verification at the applicable price.
Is the 72-hour cache the same thing as an idempotency key?
No, they are separate mechanisms. The cache key includes the normalized email address and strictness and expires after 72 hours; force_refresh bypasses it. Idempotency is separate. For API-key calls, the same route, key, and payload replay while the idempotency record remains valid (24 hours by default). Keyless x402 calls do not use that wrapper; after an indeterminate settlement, do not submit a second payment.
Do ZeroBounce, Kickbox, or MillionVerifier offer a free re-verification window like this?
No free re-verification caching window is documented for ZeroBounce (~$9.90/1k sub), Kickbox (~$10.00/1k entry), or MillionVerifier ($3.90/1k entry, down to $0.45/1k at 1M volume). No comparable free cache window was found in the reviewed pricing materials; confirm repeat-billing terms directly.
What does a cached response actually contain?
The same decision computed on the original fresh verification: the action (send, send_with_caution, review, retry_later, or avoid), the confidence score, and the normalized signals, plus a from_cache flag showing it was served from the 72-hour cache rather than a new SMTP check.
Does the cache apply per email address or per account?
Per normalized email address and strictness. With force_refresh false, an eligible lookup with the same values can return from_cache at 0 credits; a different address, different strictness, expired entry, or forced refresh runs a fresh verification.