AutoTable has separate identities for people using an application, people managing a tenant, and automated services. Choose the identity before choosing a URL. A successful application login does not grant permission to edit containers, manage accounts, or create integration credentials. Likewise, a tenant management session is not the application user whose records and interface you are testing.
Application accounts live in the project’s authentication container. An operator provisions an account through the protected managed-account endpoint, or a person registers when the project permits self-registration. Discover the configured credential fields before building a login form. There is no universal application email/password contract.
Where credentials come from
Tenant operators register through /api/v1/tenant/auth/register or sign in with an existing management account. An active membership determines the tenant they can manage. Switching to a project creates a separate project-management session; it does not sign in as an application account.
For an automated caller, an authorized manager creates an inbound integration credential and hands its one-time token to a server-side secret store. For calls from AutoTable to another service, obtain a secret from that service and save an outbound external API credential. These two credential directions have different storage and permission rules.
Identity
Acquisition
Purpose
Application user
Project login, enabled registration, or configured Google login
Use application routes under project policy
Tenant/project manager
Tenant login, then project switch when needed
Manage configuration under live membership permissions
Inbound integration
Authorized management credential creation
Call explicitly permitted runtime operations
Outbound credential
Third-party secret saved by an authorized manager
Authenticate AutoTable’s outgoing requests
Use the right session contract
Browser logins set HttpOnly cookies rather than returning access and refresh tokens in JSON. Read the session endpoint to restore application state; do not put JWTs in localStorage or invent a token field in a login response. Cookie presence alone does not establish permission for a protected action.
Authentication answers who is calling. Route authorization, roles, record access, and field projection still determine what that caller can do. Personalization can shape the experience after sign-in, while the backend remains the authority for access.