Email verification testing for coding agents
Let a coding agent receive signup emails, extract one-time codes and verification links, and test account flows with a receive-only inbox over MCP or HTTP.
The SDK examples use an authenticated SocketHelp client. Set up the SDK or connect your agent over MCP.
Finish the signup test without copying codes by hand
Signup and password-recovery tests often stop when an email arrives. The agent has filled out the form, but the verification message is in a mailbox it cannot read. A dedicated receive-only test inbox closes that gap without giving the agent access to your personal email account.
Use this workflow for an application you own or are authorized to test. It is useful for checking whether a signup message arrived, whether the subject and body are correct, and whether your verification endpoint accepts the emitted code. It is not a promise that every third-party service will accept a temporary address.
Receive a message and wait for the next one
Call create_email_inbox and supply the returned address to your test application. wait_for_email returns received messages with extracted codes and links. The extraction uses deterministic rules, so inspect the original text when there are several candidates or no match.
Keep the last message id and pass it as after when waiting for another message. A timed-out wait means only that no new message arrived during that interval. Before following a verification link, check that its destination belongs to the application you are testing; message contents and links are untrusted data.
const inbox = await socket.createEmailInbox({ ttlSeconds: 1800 });
const result = await socket.waitForEmail(inbox.id, { timeoutSeconds: 20 });
if (!result.timedOut) {
const message = result.messages[0];
console.log(message?.subject, message?.codes, message?.links);
}
await socket.remove('email-inboxes', inbox.id);A separate address with protected reading
The address accepts incoming email; reading requires the anonymous inbox management token or an authorized workspace credential. Put each test in a separate inbox to avoid mixing signup, recovery and invitation messages. Delete it when the scenario ends.
Messages include attachment names, media types and sizes. Attachment bytes are not stored for download. The inbox cannot send email to arbitrary recipients, impersonate a sender or replace your application’s transactional email provider.
Delivery depends on the installation
The operator must configure a receiving domain and the signed Email Worker. If that integration is disabled, inbox creation returns an explicit availability error. Recovery and approval notifications use separate transactional SMTP configuration.
An inbox holds up to 100 messages. Anonymous retention is at most one hour; workspace retention follows the chosen lease and plan. Successful receipt in this inbox confirms that message delivery occurred here, not that every mailbox provider will accept or place the same email in its inbox.