Register an application

Register your application at Business Apps. You need a business account before you can create an application.

Registration checklist

• Choose a name, icon, and description users will recognize on the consent screen.
• Choose test for an unpublished integration or live for a published one. Both consume real credits; see Test and live applications.
• Register the exact callback URL, such as https://your-app.example/auth/enlitt/callback.
• Configure the allowed origins for your application. An origin is the scheme and host, such as https://your-app.example; a callback URL also includes a path.
• Copy the public client ID for your login-handler configuration.

Redirect URL rules

• HTTPS, except on your own machine. A callback URL must use https:. The only exception is http: on localhost, 127.0.0.1, or [::1], for local development. The rule is the same for test and live applications.
• Exact match. The URL your server sends as redirectUri must equal a registered one character for character. A different path, scheme, port, or trailing slash fails. http://localhost:3000/auth/enlitt/callback and http://localhost:3001/auth/enlitt/callback are two separate registrations.
• Loopback IP ports. For 127.0.0.1 and [::1] only, a registered URL matches the same URL on any port, so native and command-line tools can use an ephemeral port. localhost gets no such allowance.
• Register the origin too. Add each callback's origin (scheme, host, and port, such as http://localhost:3001) to the allowed origins.
• The cookie on http://localhost. The session cookie is Secure. Chrome, Edge, and Firefox accept a Secure cookie on http://localhost; if your browser drops it, serve your development app over HTTPS.
• No wildcards, fragments, or credentials in a URL. A change takes effect at the next sign-in and does not sign anyone out.

Create the application credential

Under Business Keys, create a model key bound to this application. Copy the secret when it is returned and store it in your server's secret manager as ENLITT_SECRET_KEY. It cannot be revealed later.

You now have two different values:

You do not pass an application ID to enlitt(). The App key and personal session bind each call to the registered application and the authorizing user. A Read-only key is a separate business-wide credential for business reporting; it cannot replace an App key.

From the CLI

The CLI does the whole checklist in one step and is safe to rerun. In your project folder, after npx enlitt login (see the CLI):

npx enlitt setup --name "My App" --environment test \
  --redirect-uri https://your-app.example/auth/enlitt/callback \
  --origin https://your-app.example

It registers the application (or reuses the one in enlitt.json), writes ENLITT_CLIENT_ID and an App key as ENLITT_SECRET_KEY to .env.local, and prints variable names only, never the secret. Your server then reads both from process.env, as the login handlers do.

To change the registration later:

npx enlitt app update --add-redirect-uri https://your-app.example/auth/enlitt/callback \
  --add-origin https://your-app.example
npx enlitt app show --json        # the registered redirect URLs and origins
npx enlitt doctor --callback-url https://your-app.example/auth/enlitt/callback

doctor names any callback or origin that is not registered exactly and prints the command that fixes it. Creating a live application needs --confirm, because real users sign in to it.

Against Enlitt staging, add --env staging to every command. The full flag reference is in the CLI.

Continue with Login and sessions.