One-time passcodes are everywhere: sign up for a service, log in from a new device, confirm an action, and a six-digit code lands in your email. A human glances at it and types it in. An automated flow, a signup script, an end-to-end test, or an AI agent connecting to a third-party service, can't glance at anything. It has to pull the code out of the mailbox programmatically, and that's a surprisingly fiddly job: the code arrives seconds after a trigger, it's buried in a templated email, and every sender formats it differently.

This post covers extracting verification codes from two angles: the nylas CLI, which does it for you in one command, and the Email API pattern you build when it's part of a larger flow. I work on the CLI, so the terminal commands below are the ones I reach for when I just need the code.

Two ways to get the code

There are two paths depending on what you're building. For terminal workflows, local testing, or scripting a login, the CLI has a dedicated nylas otp command that finds the latest code in a mailbox and hands it to you. For an application or an agent that reacts to incoming mail, you build the extraction into your own flow: catch the message when it arrives, pull the body, and parse the code out.

The difference is who drives. The CLI is pull-based: you ask for the latest code when you need it. The API pattern is push-based: a webhook tells you a message arrived, and your code extracts the value as part of handling it. Both end at the same place, a string of digits you feed into whatever's waiting for it, but the CLI is the fast path for a developer and the API pattern is the durable path for a product. In practice you use both: the CLI to learn which sender and code format you're dealing with during development, then that same understanding baked into the application pattern for production.

Grab the latest code from the CLI

When you've just triggered a code and want it now, nylas otp get finds the most recent one in your default account and returns it. By default it also copies the code to your clipboard, so in interactive use you can trigger the send, run the command, and paste straight into the form. Pass an email address to target a specific connected account.

# Latest code from the default account
nylas otp get

# From a specific account, code only, no clipboard
nylas otp get user@example.com --raw --no-copy

The --raw flag prints only the code with no surrounding text, which is what you want when you're capturing it in a script: CODE=$(nylas otp get --raw --no-copy) gives you the bare value in a variable. The --no-copy flag skips the clipboard, which matters in automation where there's no clipboard to write to and you don't want the side effect. For a readable, scriptable object instead, --json returns the structured result.

Watch for a code as it arrives

Often you trigger the code first and it lands a moment later, so polling once is a race. nylas otp watch solves that by watching the mailbox and surfacing the code the instant it shows up, checking on an interval until one arrives. It's the command for the common sequence of "submit the form, then wait for the email."

# Watch for a new code, checking every 5 seconds
nylas otp watch user@example.com --interval 5

The --interval flag sets how often it checks, defaulting to 10 seconds; tightening it to 5 makes the wait feel instant in a demo without hammering the provider. Like get, it copies the code to your clipboard unless you pass --no-copy. The watch pattern is what makes a manual login flow smooth: kick off the request, switch to the terminal, and the code is waiting by the time you look.

Build extraction into your application

The CLI is perfect for a developer at a keyboard, but an agent or backend service needs the extraction inside its own logic. There's no dedicated OTP endpoint to call; instead you assemble it from pieces you already have. The reliable shape is event-driven: subscribe to the message.created webhook, and when a message arrives, fetch its body and parse the code out.

The flow is three steps. First, the webhook fires for every inbound message, so you filter down to the one that actually carries the code, usually by sender or by how recently it arrived relative to the action that triggered it. Second, you fetch that message's body with GET /v3/grants/{grant_id}/messages/{message_id}. Third, you extract the digits. Building it this way means the code lands in your workflow the moment the email does, with no polling loop of your own.

A webhook handler that ties these steps together stays small. You acknowledge the delivery fast, ignore anything that isn't the verification email, fetch the body, and extract the code:

app.post("/webhooks/nylas", async (req, res) => {
  res.sendStatus(200); // acknowledge first, then work
  const msg = req.body.data.object;
  if (!isFromExpectedSender(msg)) return;
  const full = await nylas.messages.find({
    identifier: GRANT_ID,
    messageId: msg.id,
  });
  const code = extractCode(full.data.body);
  if (code) await submitCode(code);
});

Extract with regex first, an LLM as fallback

Most verification emails put the code somewhere a simple pattern can find it, so start with a regular expression. A pattern for a standard six-digit code is enough for the large majority of OTP and 2FA emails, and it's fast, free, and deterministic.

// Pull a 6-digit code from the message body
const match = body.match(/\b(\d{6})\b/);
const code = match ? match[1] : null;

Run the pattern against the plain-text body, or strip the HTML first, so it matches the visible code and not digits hidden in inline styles or a tracking pixel. If your codes vary in length, widen the pattern to \b(\d{4,8})\b to catch four- through eight-digit codes, and anchor on a nearby word like "code" or "verification" when a message also carries other numbers. Don't over-engineer it, though: past a point, the fallback below handles edge cases more reliably than an increasingly complicated pattern.

Regex falls down on the messy cases: a code split by spaces, an unusual length, or a template where the digits sit next to an order number you'd match by mistake. That's where an LLM fallback earns its place. When the regex returns nothing or something ambiguous, hand the body to a model with a tight prompt like "extract only the login verification code from this email," and let it handle the formatting the pattern missed. Regex-first keeps the common path cheap, and the model only runs on the emails that actually need it.

Filter down to the right message

The hardest part isn't reading the code, it's making sure you read the right email. A mailbox gets other mail, and a stale code from an hour ago is worse than no code, since it'll fail the form and look like a bug. Two filters do most of the work: match the sender the codes come from, and take only messages newer than the moment you triggered the request.

Both filters are query parameters on the messages endpoint: from matches the sender address, and received_after takes a Unix timestamp so you only see mail that arrived after your trigger. A single list call with both narrows the candidates to the one message that matters, before you fetch a body or run any extraction. For an agent signing up to a service, you often know the sending domain in advance, which makes the sender filter exact rather than a guess, and the recency window can be tight because the code arrives within seconds of the request.

Use it in end-to-end tests

End-to-end tests that exercise a real login can't stub the verification step without testing a fake. nylas otp get --raw --no-copy slots into a test harness: the test submits the login form, then calls the command to retrieve the code from the test mailbox and types it in. Because the value is the real one the provider sent, the test covers the actual flow instead of a mock that drifts from reality.

A dedicated test mailbox, or a Nylas Agent Account spun up per run, keeps this deterministic. Each test gets its own inbox, so parallel runs don't grab each other's codes, and paired with the recency filter a test never picks up a stale code from a previous run. That combination is what turns a notoriously flaky part of UI testing into something that passes reliably in CI.

Put the whole flow together

The pieces add up to an agent that verifies itself with no human in the loop. The agent submits a signup or login to a third-party service using its own email address, the service emails a code, and the agent extracts it and completes the step. With the CLI that's nylas otp watch running while the signup happens; in an application it's the webhook-driven pattern firing the moment the code email lands.

This is the pattern behind automated account provisioning and agent onboarding. The agent owns a real inbox, so it receives the same verification emails a person would, and the extraction step is the bridge between "a code was emailed" and "the agent typed it in." Nothing about it requires someone to be watching the inbox, which is the entire point of giving an agent its own address.

Things to keep in mind

A short list of practices keeps OTP extraction reliable and safe.

• Use recency to avoid stale codes. An old code fails silently; always take the newest message after your trigger, not just any match.
• Never log the code. A verification code is a secret; keep it out of logs, traces, and error messages the same way you would a password.
• Treat codes as short-lived. Most expire in minutes, so extract and use immediately rather than queuing the value for later.
• Start with regex, escalate to an LLM. The pattern handles the common case cheaply; reserve the model for templates it can't parse.
• Pin the sender when you can. Knowing the sending domain up front turns a fuzzy search into an exact filter.
• Pass --no-copy in automation. The CLI copies the code to your clipboard by default, which is handy at a keyboard but a useless side effect in a script or CI run.

Wrapping up

Getting a verification code out of email is a one-liner from the terminal with nylas otp get, or a watch loop with nylas otp watch when you're waiting on a send. In an application, the same job is a small pattern: a message.created webhook tells you mail arrived, you fetch the body, and you extract the code with a regex backed by an LLM for the messy templates. Filter on sender and recency so you read the right message, never log the value, and use it before it expires.

Where to go next:

• Extract OTP codes with the CLI — the nylas otp commands in depth
• Extract an OTP or 2FA code from an agent's inbox — the webhook-driven recipe with regex and LLM fallback
• Get a message — fetch a message body to parse
• message.created webhook — the trigger that drives the pattern