Connect services
Lumis needs to connect to a few outside services to do its job — mainly your DNS (so it can point mail where it needs to go) and a mailbox (so inbound requests can turn into tickets). This page covers how those connections work, whichever service you’re connecting.
OAuth first, manual token as the fallback
For any service that supports it, connecting is a single click: choose the service, get sent to its own sign-in and permission screen, approve a narrow set of scopes, and you’re back — connected. Lumis never sees your password; it only ever receives a token, scoped to exactly what it asked for, that either side can switch off at any time.
Never paste a password or an access token into a chat message or into a Lumis text field. Passwords and tokens only ever go into your own local configuration, or directly into the provider’s own sign-in or authorization screen.
Not every service offers OAuth. Where it doesn’t, the fallback is a manually-created token:
Create a scoped token
In the provider’s own dashboard, create a token with the least access that does the job — for a DNS provider, that’s usually “edit DNS records on this one domain,” nothing broader.
Copy it once
Most providers only ever show the token a single time.
Save it locally
Put it in your own local configuration file — never in a chat message or a shared document.
Either way, the token is scoped to one purpose and revocable at any time from the provider’s side.
What Lumis does once it’s connected
Once a connection lands, Lumis does the provider-side setup itself — it doesn’t hand you a list of dashboard clicks to make. It makes the change, then reads the result back from the provider as proof that it actually took effect. Running the same setup again later is always safe: if everything’s already correct, nothing changes — a second run is a no-op, not a duplicate.
Email: the mental model
Getting inbound requests flowing into Lumis as tickets comes down to three things:
DNS points mail somewhere
Your domain’s MX record tells the internet where mail for your domain goes. This is set once, wherever your domain’s DNS lives.
Something receives it
Either a real mailbox at your domain, or a free forwarder that hands mail off to a mailbox you already have.
Lumis reads it
On a regular schedule, Lumis logs into that mailbox, pulls new messages, and triages
them: matching ones become tickets — sorted into the right project automatically if
you use address tags, like support+<project>@yourcompany.com — and everything else
is left alone.
Your options
Prices below are illustrative — confirm current pricing with the provider before you commit.
| Option | What it is | Cost (illustrative) | Best if |
|---|---|---|---|
| Free forwarding to a mailbox you already have | A DNS-level rule that bounces support@yourcompany.com into an inbox you control | $0 | You want the fastest path and already have a mailbox |
| A custom-domain add-on on your existing personal email | Some consumer email plans let you add one custom-domain address for a small monthly fee | ~$1–3/mo | You already pay for that plan |
| A dedicated small-business mailbox host | A standalone mail service just for this one address | ~$1–5/mo | You want a mailbox that isn’t tied to a personal account |
| A full email workspace suite | Company-wide email, calendar, and docs | ~$6–8/user/mo | You’re setting up company-wide email anyway — overkill for just this one address |
| Developer sending APIs | Built for sending transactional email at scale; inbound doesn’t land in a mailbox at all — it arrives through a separate delivery mechanism | $0–20+/mo | Not a fit here — Lumis needs a mailbox it can read, and this isn’t one |
Connecting your DNS
- In your DNS provider’s dashboard, create a scoped API token — edit access to DNS records on your one domain is enough; nothing broader.
- Save the token into your own local configuration.
- Lumis checks your domain’s current records, adds only what’s missing, and reads the result back to confirm. Re-running this later, after any change on your side, is always safe.