Test transactional email in WebdriverIO without fixed sleeps
Use a receive-only inbox and a wait-for-message request to verify invoice and account-change emails in WebdriverIO without guessing how long delivery will take.
InboxRhino publishes four quota levels, but only its free tier is generally live; Starter requires an access code and paid checkout remains pending.
In automated email testing, a price table can look more settled than the buying path behind it. InboxRhino’s published tiers put concrete numbers on inbox and message limits, but the status labels matter: Free is live, Starter is available with an access code, and paid checkout is not open. For teams comparing devtool pricing tiers, that distinction is as important as the quotas.
The structure also makes clear what the service meters. InboxRhino provides receive-only inboxes for signup, OTP and password-reset tests. The quotas count active inboxes and inbound emails, rather than outbound messages or a general-purpose mailbox workflow. Inboxes cannot send, reply or forward email.
The Free tier costs ₹0 and includes 11 active inboxes and 33 emails per month, with one organisation user. The site specifies that the email allowance is counted per UTC calendar month. That is a useful boundary for CI jobs: a team can plan around a fixed monthly volume, but should account for test runs that generate multiple messages or rerun after failures.
Starter lists 1,100 active inboxes and 3,300 emails per month, also for one organisation user. Both quotas are 100 times the Free limits. The listed planned price is ₹199 per month, but the tier is currently complimentary with an access code. Paid checkout is not open. The access code is therefore not a minor signup detail; it is the current route to a larger allocation, while the published price is not yet a price a team can pay through checkout.
That changes how a builder should assess the offer. Free can support a small flow or a limited set of test cases, while Starter’s larger allowance could accommodate more isolated inboxes and repeated checks. But the two plans have the same number of organisation users. Teams should not read the larger inbox count as a higher collaboration tier.
The page also lists Growth as coming soon at ₹999 per month, or ₹10,789 billed annually, with 6,600 active inboxes, 22,000 emails per month and 10 organisation users. Scale is marked coming soon at ₹2,499 per month, or ₹26,989 billed annually, with 16,500 active inboxes, 55,000 emails per month and 25 organisation users.
These figures show different quota proportions at higher levels. Growth has more than three times Starter’s inbox allowance and roughly 6.7 times its email allowance. Scale has 2.5 times Growth’s inboxes and 2.5 times its monthly email volume. That makes message volume a separate planning variable, not a simple proxy for how many test addresses a team can keep active. Since both plans are marked coming soon, those comparisons describe the published plan design, not available purchasing options.
Teams estimating test inbox quotas should map them to actual flows. A signup test might create one message; a retry, OTP resend or password-reset case can add more. The HTTP API’s wait-for-message feature waits up to 180 seconds, but waiting for a message does not remove the need to budget for each email received. InboxRhino retains messages, headers and attachments for 30 days before deletion, while the inbox remains until it is deleted.
The published amounts are in rupees, and InboxRhino’s homepage links to information about INR billing and GST invoices. That is relevant for teams buying developer tools in India, where local-currency pricing and invoice requirements can affect procurement. But the available product information does not establish that paid checkout or GST invoicing is currently operational: paid checkout is explicitly coming soon, while Growth and Scale are also not yet available.
For now, separate three questions when reviewing an India-facing SaaS pricing page: what the tier is expected to cost, whether a team can access it, and whether it can complete a paid purchase with the required billing documents. InboxRhino’s page answers the first two for some tiers, but does not make paid checkout available. Do not treat an INR amount or a GST information link as proof that a paid transaction can be completed today.
InboxRhino receives real email through Cloudflare and offers an API plus a sandboxed viewer that blocks scripts, forms, popups and remote images. Those details define the testing workflow, but they do not change the quota arithmetic. A receive-only service is a fit when the test needs to inspect messages sent by an application; it is not a substitute for a mailbox that sends replies or forwards mail.
For teams deciding how much capacity their tests need, the practical sequence is simple: count active test addresses, estimate messages per run and rerun, then check whether the tier is actually accessible. The earlier overview of real MX, safe HTML and quotas covers the operational choices behind that calculation. On the pricing side, the key distinction is availability: Free is live, Starter needs an access code, and the higher paid plans remain planned rather than purchasable.
Use a receive-only inbox and a wait-for-message request to verify invoice and account-change emails in WebdriverIO without guessing how long delivery will take.
Pair an agent runner with InboxRhino’s wait-for-message API, then keep token validation in explicit test rules rather than model judgment.
Comparing specialized receive-only test email APIs like InboxRhino, Tigrmail, and testmail.app for web application QA and CI pipelines.