Atlas, and who processes your data

"Atlas" appears in our API, in a DNS record we ask you to create, and on the sign-in screen. It has never been explained in these guides. Here it is, including what it means for your own data-protection paperwork.

What Atlas is

Atlas is the identity service that handles sign-in for Forumulate. It runs at atlasauth.net, and our instance of it answers at auth.forumulate.com.

It is our own product, operated by the same company that operates Forumulate — not an unaffiliated vendor. It has its own name and its own domain because it serves more than one property.

Since 15 September 2026, Atlas is the only way a Forumulate staff member or organization member signs in. /login sends you to /atlas-signin; the browser then holds a short-lived signed session token and a rotating refresh token, and our API verifies that token locally against Atlas's public keys and maps its subject to your Forumulate user record.

Forumulate's own password, session, Google, passkey and TOTP code was removed when that cutover happened. The credential material now lives in Atlas.

What it holds

Each Forumulate organization is mirrored as one Atlas organization. That is why enterprise SSO, SAML and SCIM directory provisioning are configured per organization and reach us through /orgs/{orgId}/atlas-enterprise/*, and why user lifecycle changes arrive at POST /atlas/webhooks.

What it does not hold

Your space readers. Readers are a separate pool. A reader signs in through the per-organization sign-in registry you configure — a password you hold, an OIDC provider of yours, a JWT from your own app — and holds a Forumulate session, not an Atlas one. See Reader sign-in.

So: your staff's credentials are in Atlas; your readers' are not.

For your data-protection records

Atlas is a subprocessor for every Forumulate account, because every staff sign-in goes through it. If you maintain an Art. 28 subprocessor list, it belongs on it, alongside the hosting, CDN, object storage, transactional email, payment and error-monitoring providers listed in our privacy policy.

If you need a signed DPA or the subprocessor list as a document, write to the address in https://forumulate.com/.well-known/security.txt.

"Your own Atlas" is a different thing

The reader sign-in registry offers a method called atlas_byo — "your own Atlas". That means you run an Atlas instance for your users and point us at it with your own frontend API URL and publishable key. It is the umbrella option for an organization that already runs an identity platform, and it has nothing to do with the Atlas instance that signs our staff in.

The two are easy to confuse because they share a name. The distinction:

The DNS record we ask you to create

Reader sign-in on your own domain asks for:

CNAME   readers.yourcompany.com   origin.atlasauth.net

atlasauth.net is Atlas. The record exists so a reader's sign-in happens on your hostname, which keeps the cookie first-party and stops a browser's third-party-cookie policy from breaking the flow. It is not a hand-off to an unrelated third party, and we should have said so on that page rather than calling it "our identity edge".

See Reader sign-in on your own domain.

The Atlas endpoints you will see in the API reference

In the API

Every operation below is also reachable from the other surfaces without a dedicated command. forumulate api <Operation> calls it from the CLI, the JavaScript SDK has a typed method for each one (the last column names it; the Python and Go clients are generated from the same spec), and an agent reaches the organization-scoped ones through the MCP call_api tool. Where a CLI command or MCP tool exists too, the last column names it. Operation names link to the API reference.

Atlas Enterprise