Pull OTP and 2FA codes from email with Nylas

Nylas has released a CLI tool and API pattern for extracting one-time passcodes (OTP) and two-factor authentication (2FA) codes from email. The CLI's `nylas otp get` and `nylas otp watch` commands allow developers to pull codes on demand or wait for new ones, while the API pattern enables event-driven extraction for automated flows. Both approaches address the challenge of parsing codes from templated emails with varying formats.

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 https://cli.nylas.com/docs/commands , 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. 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. 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. 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 https://developer.nylas.com/docs/reference/notifications/messages/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} https://developer.nylas.com/docs/reference/api/messages/get-messages-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: js 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. js // 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