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.
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.
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.
nylas otp get
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.
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."
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.
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);
});
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.
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.
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.
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.
A short list of practices keeps OTP extraction reliable and safe.
--no-copy
in automation.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:
nylas otp
commands in depth