DylogDocs

Overview

Dylog Accounts is the single identity service for every Dylog product and backend.

Dylog Accounts owns everything about a person and a tenant: sign-in, passwords, sessions, organizations, members, invitations, roles, API keys, two-factor, passkeys and the JWTs every backend trusts. Products never store credentials or roles themselves. They send people here to sign in, share the session cookie or verify a token, and read tenancy from the claims.

What you get

NeedUse
Let a person sign in to your appHand-off: /sign-in?next=<your url>
Know who is signed in (browser app)Sessions: shared cookie + get-session
Authenticate a request to a backendJWTs: RS256 token with tenant claims
Let a service or script call youAPI keys: x-api-key → JWT
Manage a tenant's peopleOrganizations UI and API
Operate everything as DylogStaff: super users plus the Infra dashboard

Where it runs

EnvironmentURLDeploys from
Productionhttps://accounts.dyloginc.workers.dev (→ accounts.dylog.ai)master
Staginghttps://accounts-staging.dyloginc.workers.devstaging
Devhttps://accounts-dev.dyloginc.workers.devmanual workflow run

Every environment is a separate Cloudflare Worker with its own D1 database and signing keys. Tokens from one environment are never valid in another.

The five-minute mental model

  1. One origin. The account UI and the API share the same host, so browser cookies are first-party.
  2. Organizations are tenants. Each carries a client-code in its metadata. That code is the key your gateway and analytics services already understand.
  3. Roles are per organization. owner, admin, member. Dylog staff are super users on top of that.
  4. Backends trust JWTs, not cookies. A 15-minute RS256 token carries user, organization and role. Verify it locally against the public key set; never call accounts per request.
  5. Sign-up is by invitation only. People join through an invitation link sent by staff or an organization admin.

Start with the Quickstart, then browse the API reference.

On this page