Antylogic
DemoApp login

399 operational guides

Docs sections
DocsAuthentication
Device

Native user registration

Create a native Antylogic account from `auth/signup`, accept the current terms, and open an app session. The action creates identity, legal acceptance, app user, and session records; it does not grant Harbor Demo Group or Harbor Soho access by itself.

In this article

Native registration is the public sign-up path for a person who does not yet have an active session. The screen loads the current terms before allowing the user to submit, so the account is tied to a specific accepted legal document.

Use this guide for operator documentation and capture planning in the GB en-GB runtime. Avoid recording a successful submit unless the documentation run uses a temporary email and cleans up the created identity, app user, cookies, and tokens afterwards.

Before you start

  • The app must be logged out; `auth/signup` is only registered while `isAuthenticated=false`.
  • A current terms and conditions document must load from `GET /api/auth/legal/terms/current`; without `termsDocument.id`, the registration action stays disabled.
  • Use an email address that is not already registered as a native identity when documenting the signup branch.
  • The app backend must be able to call the auth service internal native callback with its configured service client.
  • If a `client_id` is resolved for the session, that client must exist; non-first-party clients also need valid consent for the requested scopes.

Instructions

  1. 1.

    Open the public sign-up screen

    Open `auth/signup` while logged out. The screen shows first name, last name, email, password requirements, the terms acceptance control, and the `Get started` action.

  2. 2.

    Wait for the terms document

    The screen requests `GET /api/auth/legal/terms/current?lang=<locale>`. Continue only once a current document id is available; otherwise the submit action remains unavailable.

  3. 3.

    Review and accept terms

    Open the Terms and Conditions link when the documentation needs to show the accepted document, then accept the terms. The selected document id is sent with the signup request.

  4. 4.

    Enter account details

    Enter first name, last name, an unused email address, and a password that satisfies the visible UI policy: at least 8 characters and one special character. The app trims the names and email, then combines the names into `display_name`.

  5. 5.

    Submit registration

    Tap `Get started`. The app sends `email`, `password`, `display_name`, and `terms_document_id` to `POST /api/app/auth/callback/native`; the presence of `display_name` selects the signup branch.

  6. 6.

    Confirm the session boundary

    After success, Antylogic stores the returned tokens and leaves the public auth stack. The new app user still has no organisation, location, staff, role, TPV, booking, or Harbor Soho access unless that access is granted separately.

Validations and limits

  • First name, last name, email, password, and accepted terms are required before the UI calls the API.
  • The submit action is blocked while terms are loading, while a submit is in progress, or when `termsDocument.id` is missing.
  • The frontend requires email to contain `@`, password to have at least 8 characters, and password to include one special character; the backend evidence only proves a 6-character minimum.
  • The accepted document must be an active, required `terms_and_conditions` LegalDocument.
  • If the email already exists and `display_name` is present, the backend returns the already-registered error instead of logging the user in.
  • A successful submit creates a real native identity, legal acceptance snapshot, app user, session cookies, and access/refresh tokens.
  • The signup action does not create organisation membership, location membership, roles, staff records, TPV rights, or booking access.

Expected result

The user receives an authenticated app session backed by a native auth identity, recorded terms acceptance, provisioned app user, and issued tokens. Operational access remains separate from registration.

Related articles