RPA bots are good at forms and bad at mailboxes. A UiPath or Power Automate process can fill a registration page reliably, and then the service emails a six-digit code, and the bot has to fetch it from somewhere. The usual answer is a shared mailbox that the bot reads through Outlook or IMAP activities. That holds up for one bot running one job at a time, and breaks as soon as you scale out.

This post covers why the shared mailbox breaks, how to replace it with one inbox per bot run using plain HTTP calls to the Lumbox API, and the timeout settings in UiPath and Power Automate that decide whether those calls work.

Why the shared mailbox fails under concurrency

With one mailbox, the bot's instruction is "find the newest email from example.com and read the code". Run two unattended robots against the same service and both of them submit a form within the same minute. Both emails arrive in the same folder. Each robot picks "the newest" one, and at least one of them now holds the other's code. The service rejects it, the job fails, and the retry makes the timing worse.

Filtering harder does not fix it, because the two emails are identical apart from the code. Marking emails as read helps only if two robots never read at the same instant. What does fix it is making the address unique per run, so the question becomes "the newest email in this inbox", and there is only ever one candidate.

The four HTTP calls

Every step is a normal REST call with an X-API-Key header. Written as curl, which is also the fastest way to test them outside your RPA tool:

# 1. create an inbox for this run
curl -s -X POST https://api.lumbox.co/v1/inboxes \
  -H "X-API-Key: $LUMBOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"metadata": {"job": "vendor-portal-signup", "run": "42"}}'
# -> {"id":"inb_...","address":"...@trylumbox.com","status":"ACTIVE","created_at":"..."}

# 2. the bot types the address into the form and submits it

# 3. wait for the code (blocks up to 90 seconds)
curl -s "https://api.lumbox.co/v1/inboxes/inb_.../otp?timeout=90&from=example.com" \
  -H "X-API-Key: $LUMBOX_API_KEY"
# -> {"code":"482915","all_codes":["482915"],"from":"no-reply@example.com",
#     "subject":"Your verification code","expires":null,"email_id":"eml_..."}

# 4. clean up when the job ends
curl -s -X DELETE https://api.lumbox.co/v1/inboxes/inb_... \
  -H "X-API-Key: $LUMBOX_API_KEY"

Step 3 is a long-poll. Lumbox holds the request open, checks the inbox once a second, and answers the moment a verification email with a code arrives. If nothing matches within timeout seconds (1 to 120), it answers 408 with {"error":"No OTP found","timeout":90}. There is no polling loop to write, but the RPA tool's HTTP client has to be willing to wait that long, and the defaults are not.

UiPath: the HTTP Request activity

The HTTP Request activity (WebAPI package 2.3.0 and later) takes the method, URL, parameters and headers directly, and it has a cURL import field in the Properties panel, so the commands above can be pasted in and converted. Two of its defaults matter here.

Request timeout defaults to 10,000 ms. A 90-second long-poll aborted at 10 seconds looks exactly like "the email never came". Set it above the Lumbox timeout, for example 100,000 ms for timeout=90. The older HTTP Request (legacy) activity has a 6,000 ms default, which is even shorter.

Continue on error defaults to True. On a 408 the robot does not stop; it carries on with a response whose body has no code field, and the next activity types an empty string into the verification box. Check StatusCode on the response before parsing TextContent, or set Continue on error to False and catch the exception in a Try Catch that deletes the inbox.

The activity also has a retry policy with a configurable list of status codes. If you add 408 to that list, every retry is another full wait, which is fine as long as the job's own time budget allows it. /otp looks back five minutes by default, so a code that arrived between attempts is still returned.

Power Automate: the 120-second ceiling

In cloud flows, the HTTP action has a hard limit that Microsoft documents on its limits page: an outbound synchronous request times out after 120 seconds. Lumbox's own maximum is also 120 seconds, and the two collide: with timeout=120, the request can be cut off by Power Automate just before Lumbox answers. Keep the Lumbox timeout comfortably under the platform limit, timeout=100 or lower.

If the service is slow and you need a longer total wait, put the HTTP action inside a Do until loop that exits when the status code is 200, with a count limit so it cannot spin forever. Microsoft's own guidance for long operations points at the same pattern. Each iteration is a fresh 100-second wait, and the five-minute lookback on /otp means nothing is missed between iterations.

Automation Anywhere and others

Automation Anywhere's REST Web Services package covers the same calls with its Get, Post and Delete method actions. The two things to check there, as in every tool, are how long the action waits for a response and what it does with a non-2xx status. Any RPA platform that can send an HTTP request with a custom header can run this flow, and the no-code tools work the same way: n8n and Make each have a walkthrough with their own timeout settings.

Where the API key lives

Put the key in your platform's credential or asset store, not in the workflow file, and read it at runtime into the header. If the bots only ever touch inboxes they create, create a Lumbox project and give the robots a project key. Inboxes created with that key are pinned to the project, the key can only reach the project's inboxes, and it is refused on organisation-level routes such as domains, webhooks and bulk sending, which keeps a leaked robot credential from reaching everything else in the account.

What the parser handles, and what it does not

/otp only returns codes from emails the parser categorised as verification, and codes are read from the subject and plain-text body as 4 to 8 digit numbers. That covers the common "Your verification code is 482915" email. It misses alphanumeric codes, confirmation links, and codes in emails worded as security alerts. For those, call /wait instead with the same timeout and from parameters plus since set to the inbox's created_at. It returns the whole parsed email, with parsed.otp_codes, parsed.verification_links and text_body for the bot to read.

Limits to plan for

Each concurrent run holds one inbox, and plans cap how many inboxes exist at once: 3 on Free, 10 on Starter, 50 on Pro, 250 on Scale. Past the cap, the create call returns 402 with code: "PLAN_LIMIT_EXCEEDED", so the delete in step 4 belongs in a Finally block, not only on the success path. The API also allows 120 requests per minute per key; a run uses three or four, and a long-poll counts once no matter how long it waits.

The flow receives email. It does not get a bot past a CAPTCHA or an SMS check, and it is meant for processes your organisation is allowed to automate: your own portals, vendor systems that permit automated access, and test environments. The quickstart gets you a key and a first inbox to run the curl commands against.