Runtime Auth

Requires effective Project editor or admin. At most one type per Project may be the auth type - a concurrent enable attempt on a second type returns a clean 409 rather than silently overwriting the first. usernameField must be the type's identifier or another configured unique field (so a login can resolve it unambiguously); passwordField must be a plain string field. Disabling auth (enabled: false) invalidates every token issued for this Project and clears requiresAuth from every Route, so routes can never end up permanently unsatisfiable.

{
  "enabled": true,
  "usernameField": "email",
  "passwordField": "password"
}

{
  "typeId": 1,
  "enabled": true,
  "usernameField": "email",
  "passwordField": "password"
}

Any Mock Route create/replace request may set requiresAuth: true - independent per route, not a Project-wide switch. Only settable once this Project has a Runtime Auth type configured (422 otherwise). A gated route additionally requires Authorization: Bearer <token> on every Runtime request, checked against tokens issued by register/login below, scoped to the calling API key's own dataset instance.

A fixed Runtime API endpoint (reserved - a Type's routeName can never be register). Creates a new record of the Project's Runtime Auth type in the calling API key's own dataset instance, via the exact same path a normal POST Route would use - identifier assignment, uniqueness conflicts (409), and schema validation (422) all behave identically. passwordField's value is hashed before storage and never returned in this or any other Runtime response. Requires a read-write API key (403 for read-only) and a Project with Runtime Auth configured (404 otherwise).

{
  "email": "new-user@example.com",
  "password": "correct horse battery staple"
}

{
  "token": "opaque-runtime-auth-token",
  "record": {
    "id": 6,
    "email": "new-user@example.com"
  }
}

Resolves a record by usernameField within the calling API key's own dataset and verifies passwordField against its stored hash. Returns 401 with the same generic message whether the username was unknown or the password was wrong - a caller can never tell which. No read/read-write distinction - a read-only key may still log in, since it doesn't mutate any mock data. Same request/response shape as Register above.

Tokens never expire on a timer - only invalidated by a dataset-instance reset (POST /_mock/reset or the equivalent Admin API key-reset endpoint), disabling Runtime Auth on the type, or deleting the Project/API key. This mirrors how API keys themselves don't expire, only get revoked. The password field is never returned by any Runtime response, including a normal Route the owner also configured on the auth type - the one exception is the master Template Records endpoint (Master Template docs), which deliberately keeps the plaintext generated password so the Project owner can see a demo user's actual credentials.