<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:fh="http://purl.org/syndication/history/1.0"><channel><title>Waridex | Blog</title><description>Disposable email inboxes for automated tests: one call waits for the message and returns its OTP or link.</description><link>https://waridex.com/</link><language>en</language><fh:complete/><atom:link rel="self" href="https://waridex.com/blog/rss.xml"/><item><title>Introducing Waridex</title><link>https://waridex.com/blog/introducing-waridex/</link><guid isPermaLink="true">https://waridex.com/blog/introducing-waridex/</guid><description>Waridex gives automated tests disposable inboxes and one call that waits for an email and returns its code or link. This post explains what it does and why it works the way it does.</description><pubDate>Wed, 23 Sep 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;Most applications send email at the moments that matter most: sign-up, sign-in with a one-time code, password reset,
invitations. Those are also the flows an end-to-end test suite has the hardest time covering. The test needs an
address it controls, has to find the message when it arrives, and then has to dig a six-digit code or a link out of
HTML that was designed for people, not parsers. Waridex is built to make that part of a test short and dependable.&lt;/p&gt;
&lt;div&gt;&lt;h2 id=&quot;one-call-waits-and-extracts&quot;&gt;One call waits and extracts&lt;/h2&gt;&lt;/div&gt;
&lt;p&gt;A test creates an inbox, makes the app under test send its email there, and calls &lt;code dir=&quot;auto&quot;&gt;wait&lt;/code&gt;. The call holds until a
matching message arrives, or returns at once if it already has, and answers with the message and, with
&lt;code dir=&quot;auto&quot;&gt;extract=otp&lt;/code&gt;, the code already extracted:&lt;/p&gt;
&lt;div&gt;&lt;figure&gt;&lt;figcaption&gt;&lt;span&gt;&lt;/span&gt;&lt;/figcaption&gt;&lt;pre&gt;&lt;code&gt;&lt;div&gt;&lt;div&gt;&lt;span&gt;curl&lt;/span&gt;&lt;span&gt; &lt;/span&gt;&lt;span&gt;-sS&lt;/span&gt;&lt;span&gt; &lt;/span&gt;&lt;span&gt;-G&lt;/span&gt;&lt;span&gt; &lt;/span&gt;&lt;span&gt;&quot;https://api.waridex.com/v1/inboxes/$INBOX_ID/wait&quot;&lt;/span&gt;&lt;span&gt; \&lt;/span&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;span&gt;  &lt;/span&gt;&lt;span&gt;-H&lt;/span&gt;&lt;span&gt; &lt;/span&gt;&lt;span&gt;&quot;Authorization: Bearer $WARIDEX_API_KEY&quot;&lt;/span&gt;&lt;span&gt; \&lt;/span&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;span&gt;  &lt;/span&gt;&lt;span&gt;--data-urlencode&lt;/span&gt;&lt;span&gt; &lt;/span&gt;&lt;span&gt;&quot;to=user1@signup-k3f9x2.waridex.email&quot;&lt;/span&gt;&lt;span&gt; \&lt;/span&gt;&lt;/div&gt;&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;span&gt;  &lt;/span&gt;&lt;span&gt;-d&lt;/span&gt;&lt;span&gt; &lt;/span&gt;&lt;span&gt;extract=otp&lt;/span&gt;&lt;/div&gt;&lt;/div&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/figure&gt;&lt;/div&gt;
&lt;p&gt;There is no polling loop in the test and no HTML parsing. Codes are found when the message arrives, by patterns you
pin per sender and by deterministic scoring, never by guessing. When nothing fits, the error lists every candidate and
why it lost, so a failed test tells you what the email actually said.&lt;/p&gt;
&lt;div&gt;&lt;h2 id=&quot;one-catch-all-inbox-per-run&quot;&gt;One catch-all inbox per run&lt;/h2&gt;&lt;/div&gt;
&lt;p&gt;Every inbox has a domain of its own, such as &lt;code dir=&quot;auto&quot;&gt;signup-k3f9x2.waridex.email&lt;/code&gt;, and any address under that domain reaches
it. A CI run creates one inbox, and each test invents its own recipient: &lt;code dir=&quot;auto&quot;&gt;user1@…&lt;/code&gt;, &lt;code dir=&quot;auto&quot;&gt;reset+42@…&lt;/code&gt;, or one derived from
the test’s name. &lt;code dir=&quot;auto&quot;&gt;wait&lt;/code&gt; takes the exact recipient, so parallel tests sharing the inbox never take each other’s mail.&lt;/p&gt;
&lt;p&gt;Inboxes carry tags, usually the run that created them, and one call at the end of the run deletes every inbox of the
tag with its mail.&lt;/p&gt;
&lt;div&gt;&lt;h2 id=&quot;priced-per-workspace&quot;&gt;Priced per workspace&lt;/h2&gt;&lt;/div&gt;
&lt;p&gt;Waridex is priced per workspace, not per seat and not per inbox. A workspace groups the inboxes, API keys and patterns
of one project; everyone in your organisation can use it, and your tests can create as many inboxes as they need. The
plans differ only in how much mail a workspace receives each month, how long it is kept and how many patterns it pins.
There is a &lt;a href=&quot;https://waridex.com/pricing/&quot;&gt;Free plan&lt;/a&gt; to start with.&lt;/p&gt;
&lt;div&gt;&lt;h2 id=&quot;where-to-go-next&quot;&gt;Where to go next&lt;/h2&gt;&lt;/div&gt;
&lt;p&gt;The &lt;a href=&quot;https://waridex.com/docs/quickstarts/curl/&quot;&gt;curl quickstart&lt;/a&gt; runs a whole test in four calls, and the
&lt;a href=&quot;https://waridex.com/docs/concepts/inboxes-and-domains/&quot;&gt;concepts&lt;/a&gt; explain inboxes, &lt;code dir=&quot;auto&quot;&gt;wait&lt;/code&gt;, extraction and keys in more detail. Every
error the API returns links to &lt;a href=&quot;https://waridex.com/problems/wait.timeout/&quot;&gt;a page&lt;/a&gt; that says what it means and what to do.&lt;/p&gt;
&lt;p&gt;Questions and feedback are welcome at &lt;a href=&quot;mailto:support@waridex.com&quot;&gt;support@waridex.com&lt;/a&gt;.&lt;/p&gt;</content:encoded><category>announcement</category></item></channel></rss>