An agent can potentially read an SMS verification code by having a customer-controlled phone automation forward the relevant text as email, then retrieving a parsed code from that inbox. In this design Lumbox receives email; it does not supply the phone automation, a mobile number or a native SMS-receiving endpoint.
That boundary is the most useful starting point for a portal-agent team. A portal may already send codes to the customer’s established phone number. A relay can preserve that destination while making selected messages available to the authorized workflow. Whether it works depends on the phone, automation permissions, message template and portal behavior.
This is an integration design to test, not a claim of a shipped Lumbox SMS product or a completed cross-device benchmark. It should be evaluated with the customer who controls the number and a test account the team is allowed to operate.
Map the route in plain terms
The portal sends a text to the customer’s phone. An automation on that phone selects an eligible message and sends its content to an inbox assigned to the workflow. Your application retrieves the code from Lumbox and supplies it to the correct browser challenge.
| Stage | What must exist |
|---|---|
| Portal to phone | A working, customer-authorized SMS destination |
| Phone selection | A narrow rule for relevant messages |
| Phone to email | A configured action or relay that sends an email |
| Email to parsed code | Receipt and parser compatibility in Lumbox |
| Code to browser | Application correlation and a defined login outcome |
The phone remains a dependency. If it cannot receive messages or run the automation, an inbox API cannot compensate. A successful relay test while the phone is unlocked does not establish the behavior of every background or locked-device state.
What iPhone documentation establishes
Apple documents communication triggers for Shortcuts, including Message triggers filtered by sender or message contents. That establishes a way to select incoming messages as an automation trigger. It does not by itself prove that your full forwarding workflow runs unattended on every device configuration. See Apple’s communication-trigger guide.
Use those filters to keep the proposed automation specific to the portal workflow. Configure an appropriate email action or your own relay, then test the entire path on the actual phone. Check permission prompts, background execution and what data the action receives. Treat observed device behavior as part of the pilot record.
For Android, select a forwarding application or customer-managed integration only after checking its current permissions and behavior. This guide does not recommend an untested app or claim a universal Android setup. The downstream email contract can remain the same even when the upstream relay differs.
Preserve enough context to diagnose a failure
Do not forward a bare number without context if the application needs to distinguish attempts. Preserve the original message text and enough information to identify the intended service. Keep the customer’s sensitive information out of ordinary application logs and public demo captures.
The email’s sender will usually identify the relay or forwarding account, not authenticate the original SMS sender. Lumbox’s from filter checks the received email sender with a substring match. It cannot prove which phone originally received the text or which portal issued the code.
Your application should map the relay destination to the authorized customer workflow. For concurrent logins, record the attempt start time and avoid two active challenges sharing an ambiguous route. A relay can make a code accessible without making its ownership unambiguous.
Test extraction with the actual forwarded template
Lumbox extracts codes with patterns and classifies messages with rules. Its OTP shortcut requires a verification-category message containing extracted codes. A text that contains digits is not automatically suitable for that shortcut.
Start by inspecting the received email using the email tools and fields. Check whether the forwarded body preserves the code and whether the category matches the retrieval path. If the relay reformats content, test the final email rather than only the original SMS screenshot.
Use a plainly labeled synthetic verification message for an initial mechanical test. Then test representative, authorized portal messages. Do not rewrite a real message merely to hide a parser failure in a demo. Record unsupported templates as unsupported until the integration handles them.
Retrieve through the email API
Once the message route is established, GET /v1/inboxes/:id/otp can wait for a suitable email. Set a timeout appropriate to the browser task, up to 120 seconds. For REST, supply since from the start of the login attempt and a from value based on the relay’s received email identity.
A successful response returns code with related fields including email_id. HTTP 408 means no suitable code was found before the wait ended. It does not identify whether the phone, relay, mail delivery, filter or parser caused the failure. The API reference describes the email interface.
“One call” applies to this retrieval request after the inbox and forwarding route exist. Provisioning, customer setup, SMS delivery and browser entry are separate steps. The complete flow is not a single Lumbox API call.
Plan the customer handoff
Define what happens when the relay fails before enrolling a real workflow. A customer might enter the code manually, resume the browser session, or retry after checking the device. The right choice depends on the portal and the customer’s expectations.
Also define who owns the automation and how it is disabled when access ends. A rule on a personal phone can outlive a particular agent run. The team should be able to explain which messages are forwarded, to which address, and how the customer stops that behavior.
Avoid claiming automatic alerts, customer code copies or relay health monitoring unless your application actually implements them. Those are sensible product ideas, but the inspected Lumbox email source does not turn them into shipped SMS features.
Decide whether this is the right route
Phone forwarding is worth testing when the customer wants to keep the portal’s current phone destination and can maintain the relay. A human handoff may be simpler when codes arrive rarely or the device configuration is unreliable. A dedicated SMS service is a different option, with its own number acceptance and integration requirements.
For Lumbox, evaluate the part it actually provides: receiving the forwarded email and returning a parsed code. Implementation references are apps/api/src/routes/inboxes.ts, apps/api/src/utils/parser.ts, and apps/docs/content/docs/emails.mdx, checked October 3, 2026. No native SMS endpoint was found in the inspected route and tool source.
Kumar