Guide

Build a Signup & Verification Bot

An agent that registers for services hits the same wall a person does: a verification code emailed to an address it has to be able to read. An agent account solves it — the agent owns a real, deliverable inbox, and one CLI command pulls the latest code out of it. This guide gives a signup bot its own email identity, reads verification codes with a single command, waits for codes that haven't landed yet, and ties it into a signup loop — with a clear note on staying inside each service's terms.

Written by Hazik Director of Product Management

Verified — CLI 3.1.16 · Nylas managed · last tested June 8, 2026

What is a signup & verification bot?

A signup and verification bot is an agent that registers for an online service and completes the email verification step on its own. The blocker is always the same: the service emails a one-time code to the address used at signup, and the agent has to read that inbox to continue. An agent account gives the bot a real, deliverable email address it owns — so the verification code lands somewhere the agent can actually read it.

This is email as the identity layer for an agent. A code emailed to a temporary or fake address never arrives or can't be read; a code emailed to an agent account lands in an inbox the agent controls, and the CLI pulls it out in one command. The same pattern covers magic links and account-recovery flows — anywhere a service proves you own an address. For the broader identity model, see email as the identity layer for AI agents.

Signup flow: sign up with the agent's address, a code arrives in its inbox, the agent reads it, and submits to verifySign upagent's addressCode arrivesto agent inboxRead OTPnylas otp getSubmit codecomplete signup

Why give the bot its own agent account?

A signup bot needs an address that actually receives mail, which rules out the throwaway and plus-aliasing tricks people reach for. Many services reject known disposable-email domains outright, and a plus-alias still depends on a human mailbox. An agent account is a first-class managed inbox: it accepts the verification email, and the agent reads it without a person in the loop.

Owning the identity also keeps things contained. Each bot can have its own account, so one workflow's signups don't mix with another's, and you shut a bot down by deleting one grant. Because the inbox is the agent's own, the codes it receives are scoped to that agent — no shared mailbox where one bot can read another's verification codes.

How do I create the bot's email identity?

Create the bot's inbox with one command. The nylas agent account create call returns a deliverable address in under 2 seconds. Use this address wherever the bot signs up:

nylas agent account create bot@yourapp.nylas.email

The address is live immediately, so a verification email sent a second after signup will arrive. Because it's a real managed inbox rather than a disposable domain, it passes the deliverability checks services run on the signup address.

How does the bot read a verification code?

The CLI extracts the code for you — no inbox parsing, no regex over message bodies. The nylas otp get command scans recent messages, finds the latest verification code, and returns it. Add --raw to print just the code and --no-copy to skip the clipboard in a headless environment:

code=$(nylas otp get bot@yourapp.nylas.email --raw --no-copy)
echo "verification code: $code"

The command works across providers and pulls the code in under a second, so the bot doesn't parse email at all — it asks for the code and gets a string. That keeps the brittle part of OTP handling, reading a code out of a templated email, inside the CLI instead of your bot. For the underlying extraction patterns, see extracting OTP codes from email.

How does the bot wait for a code that hasn't arrived?

A verification email takes a moment to arrive, so a bot that calls otp get the instant it submits the form may read nothing. The nylas otp watch command blocks until a new code lands, so the bot waits exactly as long as it needs to instead of polling on a fixed timer:

# Submit the signup form first, then wait for the code to arrive
nylas otp watch bot@yourapp.nylas.email

Watching turns a race into a wait: the bot triggers the email, then blocks until the code arrives rather than guessing how long delivery takes. For an unattended loop, wrap the watch in a timeout so a code that never arrives fails the run instead of hanging it.

How do I build the signup loop?

The loop ties your signup automation to the CLI's code reading. The signup and the code submission are your bot's own steps — a browser driver like Playwright or an API client — and the CLI fills the gap in the middle: reading the verification code from the agent's inbox. The skeleton shows that spine:

#!/usr/bin/env bash
set -euo pipefail

agent="bot@yourapp.nylas.email"

# 1. Your automation submits the signup form with the agent's address
submit_signup "$agent"          # e.g. a browser-driver or API call

# 2. Read the latest code (swap for 'otp watch "$agent"' to block until it arrives)
code=$(nylas otp get "$agent" --raw --no-copy)
[ -z "$code" ] && { echo "no code yet" >&2; exit 1; }

# 3. Your automation submits the code to finish verification
submit_code "$code"
echo "verified $agent"

Only the middle step is Nylas; the submit_signup and submit_code functions are your own automation against the target service. The CLI removes the one part that's genuinely hard for a bot — getting a code out of an inbox — and leaves the rest to your tooling.

How do I keep the bot inside the rules?

Automating signups is powerful and easy to misuse, so the constraints matter. Only sign up for services you're authorized to use, and respect each one's terms — many prohibit automated registration, and bypassing a CAPTCHA or creating accounts at scale crosses from automation into abuse. Build the bot for your own provisioning and testing, not for mass account creation.

On the agent-account side, the usual controls apply. A bot inbox receives untrusted mail, so contain its outbound with a workspace rule and a policy send cap, and rotate or delete the grant when the bot retires. The NIST 800-63B guidance treats an emailed code as a one-time secret — short-lived and single-use — so read it once and don't store it. For the containment pattern, see Stop Your AI Agent From Going Rogue.

Next steps