Accounts, approval and API keys

A developer account is separate from any household account, even when both use the same email address. You sign up with name, email, password, developer type, terms acceptance, and a bot check. After email verification, the account becomes active, a private sandbox is created, and the browser session opens the dashboard. App secrets belong to DEV or LIVE credentials, and Verification does not issue an application secret; Create an app before creating credentials. DEV credentials are for the developer’s sandbox, while LIVE credentials are only for the connector installations that belong to the published connector. Credential rotation uses seven-day overlap, and password recovery and two-factor sign-in follow their own rules.

Account and session

A developer account is its own account. The same email on a household account does not give access to the developer dashboard, and a developer session does not open the household console.

Signup requires:

• name
• email
• password
• developer type
• terms acceptance
• bot check

The verification email link is one-use and expiring. When it is used, it activates the account, creates the private sandbox, opens a browser session, and sends the developer to the dashboard. If a second factor was already configured, the normal sign-in flow still applies.

The developer header shows Dashboard, Reference, and Docs in that order. The account menu appears on desktop and on narrow web screens. Docs remain readable without signing in.

Sign in and sign out

Sign in uses POST /developers/auth/login with email and password, and totp when MFA is enabled. Access tokens last 15 minutes. Refresh tokens last 30 days and rotate on use.

Signing out clears the browser session and the tab’s saved reference credential, and revokes the refresh token. Existing access tokens expire on their own.

An application credential cannot manage the developer account. Sessions and application credentials are separate.

Verification and resend

If the original verification link is lost, request another one with POST /developers/resend-verification. Send email and a fresh turnstileToken. The response does not reveal whether an account exists.

A verification link works once. If it has already been used, the page sends the user to sign in instead of reusing it.

Applications before credentials

Create an app before creating credentials. The dashboard shows one tile per app with:

• name
• logo
• publisher
• description
• stable App ID
• latest development or review state
• current production version

A new draft does not hide an older production version.

Each app tile links to Credentials, Versions and review, AI settings, and Test homes. All of a developer’s apps share the same private sandbox, which starts with five virtual devices provisioned in the background.

Before creating DEV credentials, complete the app listing, safe SVG logo, publisher website, support and privacy URLs, connector specification, runtime URL, guide, and release notes. The runtime does not need to be running yet. When you submit for review, provider test values and a successful runtime probe are required.

GET /developers/applications returns the owned apps and also shows any missing credential requirements.

Credentials and access boundaries

App secrets belong to DEV or LIVE credentials. They are shown once, either when created or when rotated.

POST /developers/keys requires a name and the owned app’s definitionId. Use that definitionId as the stable App ID.

DEV credentials reach only the developer’s sandbox. LIVE credentials require an approved or published version and reach only that connector’s installations. Household installation establishes the access boundary; approval alone grants no household access.

Select only the scopes the app needs. The current published scope catalogue includes the DEV default set and the LIVE set. DEV scopes exclude ai:chat; for approved ALYT local inference, use a dedicated app AI credential or your own provider key. LIVE credentials are limited to things:read, things:control, integrations:read, events:read, and webhooks:write.

The runtime token authenticates incoming ALYT requests to the connector server. It is separate from the App secret used for outgoing API requests.

Rotation and recovery

Credential rotation has a seven-day overlap, capped by any earlier predecessor expiry. The App ID stays stable for application-bound credentials. Revoking a credential stops that credential; it does not revoke the successor. Existing legacy unbound credentials remain usable and rotatable, but new ordinary unbound credentials cannot be created.

Password reset uses POST /developers/auth/forgot-password. The mailed reset link lasts one hour and works once. Completing the reset replaces the password and revokes all refresh sessions. If the password is changed while signed in, the current refresh session can remain, while the other refresh sessions are revoked. Access-token expiry is separate.

Two-factor sign-in

Optional TOTP MFA uses six-digit authenticator codes. When enabled, eight one-use recovery codes are shown once.

Setup gives a candidate secret. A valid code confirms enablement. After that, sign-in requires totp; if it is missing, sign-in returns 401.

Turning MFA off requires the password and a valid TOTP or unused recovery code, and it revokes all refresh sessions. SMS is not supported.

Account details on the dashboard

The account page shows:

• name
• email
• developer type
• organisation, if present
• verified badge status and date
• member since date
• sandbox tenant ID

It also shows current ceilings and whether each limit has a burst allowance. Those ceilings are read-only account information.

What developers can rely on

• Verification opens the developer session and sandbox, but not an application secret.
• Create an app before creating credentials.
• App secrets belong to DEV or LIVE credentials.
• DEV credentials are for the developer sandbox only.
• LIVE credentials are for the connector installations of an approved or published version only.
• Credential rotation keeps the old and new credential valid together for seven days, unless the older one expires earlier.
• A password reset link works once and lasts one hour.
• MFA uses six-digit codes and eight recovery codes.
• SMS is not supported.