Make has no Lumbox app, so the connection runs through Make's own HTTP app and its Make a request module, pointed at the Lumbox REST API. A scenario that verifies an email address needs three of those modules around whatever step submits the signup: one to create an inbox, one to wait for the verification email, one to delete the inbox afterwards. Most of the work is in the settings of the middle one.

This walkthrough uses the current HTTP app (Make lists it as Version 4) and calls out where the legacy Version 3 modules behave differently.

Store the key once, in a keychain

Lumbox takes the API key in an X-API-Key header. In the Make a request module, set Authentication type to API key and create a keychain with:

  • Key: your ak_... key, with no prefix (Lumbox does not want Bearer in this header)
  • API key placement: In the header
  • API key parameter name: X-API-Key

Every HTTP module in the scenario can then pick the same keychain, and Make's own docs recommend this over typing the key into the Headers field, since the key stays out of the request configuration and can be rotated in one place. The content type for JSON bodies has its own field too, so the Headers section stays empty.

Module 1: create the inbox

URL:                https://api.lumbox.co/v1/inboxes
Method:             POST
Body content type:  application/json
Body input method:  JSON string
Body:               {"metadata": {"source": "make"}}
Parse response:     Yes

Lumbox answers 201 with id, address, status and created_at. With Parse response on, those become mappable fields after you run the module once. The address is on trylumbox.com unless you have a verified custom domain. Leave name out of the body and Lumbox generates the local part; a name you pick is shared with everyone else on that domain, so a taken one returns 409.

Module 2: your signup step

This is whatever hands the new address to the service: an HTTP call to your own app's signup API, a module for a service that has a Make app, or a request to a browser automation service. Map address from module 1 into it.

Module 3: wait for the email

Lumbox has two long-poll endpoints, and which one you use depends on what the service sends.

If it sends a numeric code, use /otp:

URL:     https://api.lumbox.co/v1/inboxes/{{1.id}}/otp
Method:  GET
Query:   timeout = 90
         from    = example.com
Advanced settings:
  Return error if HTTP request fails: Yes
  Timeout: 100

The response carries code, all_codes, from, subject, expires and email_id. Map code into the module that submits it. /otp only looks at emails the parser put in the verification category, and it reads 4 to 8 digit codes from the subject and plain-text body. It also looks back five minutes by default, so an email that landed while module 2 was still running is found.

If the service sends a confirmation link, use /wait, which returns the full parsed email:

URL:     https://api.lumbox.co/v1/inboxes/{{1.id}}/wait
Method:  GET
Query:   timeout = 90
         from    = example.com
         since   = {{1.created_at}}
Advanced settings:
  Return error if HTTP request fails: Yes
  Timeout: 100

The link is in parsed.verification_links. Make arrays start at index 1, so map it as {{get(3.parsed.verification_links; 1)}} and feed it to an HTTP module that requests the URL, or to your browser step if the confirmation page runs JavaScript. The same response also has parsed.otp_codes (codes found in any category, not only verification) and text_body for anything the parser does not pick up, such as alphanumeric codes.

Set since on /wait. Without it, /wait only returns mail that arrives after the request starts, and a fast sender can beat module 3 to the inbox. Mapping created_at from module 1 uses the Lumbox server's own clock. If you would rather use Make's clock, now works too: Make converts a date to ISO 8601 text when you map it into a text field, which is the format Lumbox parses.

The timeout has to cover the long-poll

The timeout query parameter is how many seconds Lumbox holds the request open, clamped to 1 through 120. The module's own Timeout (in seconds, 1 to 300 in Version 4) is how long Make waits for a response. Lumbox sends nothing until it has an answer, so the module timeout must be longer than the Lumbox one, or Make gives up while the email is still on its way. Make's documentation lists a default of 40 seconds for the legacy Version 3 HTTP modules, which is shorter than the 90-second wait used here. Set the field explicitly in either version.

Error handling: the 408 and the cleanup

When nothing matches before the timeout, Lumbox returns 408: {"error":"No OTP found","timeout":90} from /otp, or {"error":"Timeout: no matching email received","timeout":90} from /wait. With Return error if HTTP request fails set to Yes, that becomes a module error, which is what you want: it stops module 4 from running with an empty code.

Attach an error handler route to module 3. Make offers five handlers: Skip, Retry, Resume, Commit and Rollback. A practical route here is an HTTP module that deletes the inbox, followed by a notification, ending in Commit or Skip depending on whether the rest of the bundle should stop. Resume lets you substitute a value and continue, which is rarely right for a missing verification code. Retry is reasonable if the service is known to be slow; /otp's five-minute lookback means a code that arrived between attempts still counts, and each attempt is another full wait.

The success path needs the same delete at the end:

URL:     https://api.lumbox.co/v1/inboxes/{{1.id}}
Method:  DELETE

Deleting matters for a practical reason. Plans cap how many inboxes exist at the same time: 3 on Free, 10 on Starter, 50 on Pro, 250 on Scale. Past the cap, module 1 fails with 402 and code: "PLAN_LIMIT_EXCEEDED". On the Free plan, a scenario that creates an inbox per run and never deletes one fails on its fourth run, sooner if the account already has inboxes.

There is one case for keeping the inbox: when the account you created is going to be used again. Password resets and new-device codes will go to that address later, and Lumbox inboxes do not expire. Store the inbox id next to the account in a data store instead of deleting it.

Checking the scenario before it matters

Run the scenario once with "Run once", temporarily set the from filter to your own mail domain, and send a test email to the new address from that mailbox, with a subject like "Your verification code" and a body containing "Your code is 123456". Module 3 should return within a second or two of delivery, with code set to 123456. If it returns 408 instead, check three things in this order: the sender filter (it is a substring of the sender address, so a typo there matches nothing), the category (a subject without verification wording can land in another category, which /otp ignores), and the module timeout.

Where this stops

The scenario handles the email. It does nothing about CAPTCHAs, phone verification or bot checks on the signup form, and it does not change what a service's terms allow. The intended uses are your own product's signup and onboarding checks, staging environments, and services that permit accounts created by software. The n8n version of the same flow, with notes on its HTTP node timeouts, is in n8n email OTP workflow; how the code is pulled out of the email is covered in OTP extraction techniques, and the inboxes docs list every query parameter for /otp and /wait.