Developer tools

Part 5 of the visual dashboard tour. These six screens are the ones your engineers wire up once, near the start. As a non-developer you rarely change them day to day — but knowing what each does helps you understand how Atlas connects to the rest of your product, and one of them (Custom domains) directly fixes the most common sign-in problem, so it's worth reading.

Dev Console

Open Dev Console. Two things live here: API keys and Webhooks.

• API keys — the secret key your backend uses to call Atlas securely. Unlike the publishable key at the top of every screen, this one must stay server-side. Click Add key to create one; you'll see it once, so it gets copied into your app's configuration.

• Webhooks — Atlas can notify your systems the instant something happens (a user signs up, an organization is created, and so on) by calling a URL you provide. This is how Atlas keeps the rest of your product in sync.

Custom domains

Open Custom domains. This is the single most important setting for a smooth login, so don't skip it.

By default, Atlas serves sign-in from a shared address. That works for testing, but in production it means the sign-in cookie is a third-party cookie — and modern browsers block those, which quietly breaks login for many of your users. The fix is to point a domain you own (like login.yourcompany.com or auth.yourcompany.com) at Atlas. Click Add domain, add the DNS record Atlas shows you, and once it verifies, sign-in runs from your own domain as a first-party cookie — reliable in every browser. Atlas warns you in amber until you've done this. If login ever feels flaky, check here first.

OAuth & APIs

Open OAuth & APIs. This turns Atlas into an identity provider for other apps — the "Sign in with [your product]" button on a partner's site.

• OAuth applications — register a third-party app so its users can sign in with your product's accounts.

• Protected APIs — describe your own APIs so Atlas can issue and check access tokens for them.

Most products don't need this early; it becomes relevant when you build an integration platform or a partner ecosystem.

Connectors

Open Connectors. These are specialised federation standards used in specific industries.

• LTI Platforms — register a learning-management system (Canvas, Moodle, etc.) so your app launches inside it as an education tool.

• RADIUS Clients — let network equipment (Wi-Fi, VPN) authenticate against Atlas.

• SCIM provisioning — automatic account creation/removal for enterprise customers.

You'll only touch this if your product plays in education, networking, or large enterprise.

JWT templates

Open JWT templates. A slightly technical but useful one: it lets you add custom information to the secure token Atlas hands your app when someone signs in.

If a downstream system (for example a database like Supabase, or an analytics tool) needs a specific piece of information baked into the login token — a role, a plan tier, an organization ID — you define that here as a named template. An engineer usually sets this up to make Atlas play nicely with another tool you use.

Messaging

Open Messaging. Atlas sends emails (verification codes, magic links) and text messages (SMS codes). This screen is where you decide who actually delivers them.

• On the Free plan, you connect your own email and SMS provider (like SendGrid or Twilio) — click Add provider and paste the credentials.

• Or upgrade your plan and let Atlas handle sending for you, with no provider setup at all.

If your users report that codes or emails aren't arriving, this is the screen to check.

Next: running it day to day →