Source: https://cli.nylas.com/guides/signup-otp-bot-agent-account

# 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](https://cli.nylas.com/authors/hazik) Director of Product Management

Updated June 8, 2026

> **TL;DR:** Give the bot a real inbox with `nylas agent account create`, sign up using that address, then pull the verification code with `nylas otp get --raw` or wait for it with `nylas otp watch`. Respect each service's terms.

## 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](https://cli.nylas.com/guides/email-as-identity-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`](https://cli.nylas.com/docs/commands/agent-account-create) call returns a deliverable address in under 2 seconds. Use this address wherever the bot signs up:

```bash
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:

```bash
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](https://cli.nylas.com/guides/extract-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:

```bash
# 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](https://playwright.dev/) 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:

```bash
#!/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](https://pages.nist.gov/800-63-3/sp800-63b.html) 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](https://cli.nylas.com/guides/stop-ai-agent-going-rogue).

## Next steps

- [Email as the Identity Layer for AI Agents](https://cli.nylas.com/guides/email-as-identity-for-ai-agents) — OTP, magic links, and account recovery as agent identity
- [Extract OTP Codes from Email](https://cli.nylas.com/guides/extract-otp-codes-from-email) — the underlying code-extraction patterns
- [Getting Started with Agent Accounts](https://cli.nylas.com/guides/getting-started-agent-accounts) — the managed inbox the bot signs up with
- [Manage the Agent Account Lifecycle](https://cli.nylas.com/guides/agent-account-lifecycle) — rotate or delete the bot's identity when it retires
- [Stop Your AI Agent From Going Rogue](https://cli.nylas.com/guides/stop-ai-agent-going-rogue) — contain the bot's inbox and outbound
- [Full command reference](https://cli.nylas.com/docs/commands) — every `nylas otp` and `nylas agent` flag
- [Nylas v3 API documentation](https://developer.nylas.com/) — the messages API behind OTP extraction