Build a Postman collection for signup email verification

Email verification is often the missing step in an otherwise useful API test. A signup endpoint can return success while the application fails to send its verification message, sends it to the wrong address, or renders a broken code. A Postman collection can test that path in sequence: create a test inbox, submit a signup request using its address, wait for the message, and assert on the content.

InboxRhino provides receive-only test inboxes through an API. Its wait-for-message request can wait up to 180 seconds and filter by subject or sender. Postman supplies the request sequence and test scripts; it does not replace the application’s mail delivery path. The app still has to send the message to the test address.

Set up the collection and variables

Create a Postman environment with an InboxRhino API key and a base URL for the application under test. Keep the API key in a secret environment variable rather than embedding it in a shared collection. Add variables for the InboxRhino inbox ID and address; the collection will populate those after creating an inbox.

Use three requests in this order: create an inbox, submit signup, and retrieve the matching email. Postman’s collection runner can run them in sequence. Keep application-specific details, such as the signup route and required user fields, in the signup request rather than assuming every app uses the same contract.

Create an address, then submit signup

For the first request, send a POST to https://api.inboxrhino.in/v1/inboxes with bearer authentication using the API key. The documented example does not require a request body. In the Postman test script, parse the JSON response and save data.id as the inbox ID variable. Save the returned address too, using the address field shown in the response. Check the response before continuing; if inbox creation fails, the next request should not run with an empty address.

In the signup request, pass that saved address in the field your application expects. Add assertions for the signup response, but do not treat a successful response as proof that email verification works. It only establishes that the application accepted the signup request.

InboxRhino addresses are real MX addresses on test.inboxrhino.in routed through Cloudflare, not a local SMTP sandbox. That makes the test useful for checking the application’s real outbound delivery path, but it also means the environment and mail configuration must allow delivery to the address. For background on the trade-offs involved, see how real MX receipt, safe HTML inspection and quotas shape email testing.

Wait for the message in Postman

Set the third request to GET the inbox messages endpoint using the saved inbox ID: https://api.inboxrhino.in/v1/inboxes/{{inboxId}}/messages. Add the query parameters wait_seconds=180, limit=1, include=content, and a subject filter that matches the app’s verification email. The documented example uses subject=Verify. Use the exact subject text your application sends, or a distinctive part of it; a loose filter can select an unrelated message.

Authenticate this request with the same bearer token. The wait parameter gives delivery time to complete without adding an arbitrary pause before every check. It can still take up to 180 seconds, so this collection is slower than a test that stops at the signup response. If no matching email arrives, let the request fail clearly rather than reporting a successful verification test.

In the response tests, first confirm that a message exists and that its subject matches the expected email. InboxRhino’s documented example reads the subject at data[0].subject. Inspect the returned response to identify the parsed body field before writing a content assertion; the field name and email structure are application- and response-specific.

Assert on the code, not just delivery

For an OTP flow, write a test against the actual template text and code format. For example, if the email says “Your verification code is” followed by six digits, extract digits following that phrase and assert that a match exists. Then assert the expected length or format. A generic search for any six-digit number can pass on an unrelated invoice number, so anchor the match to the wording the app sends.

For a verification link, assert that the message contains the expected link pattern and that its host is the application’s test host. Avoid printing full tokens into shared Postman reports: verification links may grant access until they expire or are used. The test should check the link’s presence and structure, not expose its secret value in logs.

Know the limits of the stack

InboxRhino inboxes cannot send, reply, or forward. They receive messages only, so they suit checking outbound signup mail, not testing a reply workflow. Messages are retained for 30 days before deletion. The free tier offers 11 active inboxes and 33 emails per month for one user, a practical ceiling to account for when a collection runs repeatedly or across a team.

The mailbox viewer is sandboxed and blocks scripts, forms, popups, and remote images. It can help a tester inspect the received HTML safely when an assertion fails, but visual inspection is not a substitute for the Postman checks. Keep the collection’s pass condition explicit: signup accepted, matching message received, and the required code or link present in the expected format.