Skip to main content

Registration

Outside-registered Consumers — people who sign themselves up rather than being invited from /org — reach the platform through one of two registration routes:

  1. The hosted public sign-up form at /registration (this page). The Consumer fills it in directly.
  2. Partner-driven external registration — a partner collects the details in their own UI and drives the sign-up through Keen's registration API. See Partner-driven external registration below.

Both routes are gated by the outside-registration switch and seed the new Consumer's Spaces the same way.

When this page is reachable​

/registration (and the partner-driven route) is only available when outside registration is enabled:

  • First-party deployment — /org/system/settings-consumer → Allow customer to be registered outside the system → Yes.
  • Partner-integrated deployment — the tenant contract's outsideRegistration flag acts as a kill-switch; when it is off, both routes are refused.

When disabled, the page is unreachable and the "Sign up" link on /login is hidden.

Form fields​

FieldNotes
Email addressWhere the activation link is sent.
Gender"Select gender" dropdown.
First name / Last nameTwo side-by-side fields.
Date of birthThree columns: Day / Month / Year.
Password / Confirm passwordStandard double-entry.
Terms of Service / Privacy PolicyRequired checkbox: "I have read and agree to the Terms of Service and Privacy Policy".
Sign UpSubmit button.
"Be back soon. Sign In"Link back to /login.

Activation contract — important​

When the form is submitted:

  1. No Consumer record is created yet. The system holds the request pending.
  2. The submitter receives an activation email with a 24-hour-valid link.
  3. Only when the link is clicked does the actual Consumer record get created.
  4. After successful activation:
    • A welcome email is sent.
    • The Consumer is redirected to /login.
  5. If the link expires or is otherwise invalid, the user sees an error message ("activation link expired" or similar).

This means an unclicked registration leaves no trace in the system — clean by design.

What Spaces does the new Consumer get?​

Outside-registered Consumers are auto-assigned a set of default Spaces at activation:

  • Partner-integrated deployment — the new Consumer's Spaces are seeded from the tenant contract's default outside-registration Spaces.
  • First-party deployment — seeded from /org/system/settings-consumer → Consumer Spaces.

Whatever Spaces apply at the moment the account is activated are what the new Consumer sees on / after their first login. From then on the visible set is re-clamped to the tenant's current Spaces on every login, so a later revocation drops the Space (see Spaces page).

(Compare: system-registered Consumers get Spaces assigned manually from their consumer-edit page in /org as the documented default. On partner-integrated deployments the tenant contract also defines a defaultSystemRegisteredConsumerSpaces set that may seed system registrations as a starting grant — but source documents only the outside-registration seed as wired end to end, so confirm contract-seeded system defaults against your deployment. See consumers.md.)

Partner-driven external registration​

Instead of sending users to the hosted /registration form, a partner can register Consumers from their own UI through Keen's two-step registration API. The shape, end to end:

  1. Claim. The partner's backend calls POST /keen-api/consumer/registration-claim with the user's details (email, name, gender, date of birth, password, consent) using its server-to-server application token. Keen validates the tenant, mints a short-lived signed claim token, and emails the user a verification link carrying that token. No Consumer record exists yet.
  2. User clicks the verification link — it returns to the partner's confirm-back page with the claim token.
  3. Redeem. The partner's UI calls POST /keen-api/consumer/registration-redeem with the token to finalize. Keen re-validates the tenant and the token's expiry, then creates the Consumer record (seeded with the tenant's default outside Spaces, exactly like the hosted form).

The claim token is self-describing and signed: it is verifiable with the tenant's certificate public key, so the partner can decode it client-side and pre-fill the user's confirmation screen before the redeem call — no server-side claim table is kept. The token carries a short validity window (about 10 minutes); an expired or replayed redeem is rejected.

What's intentionally not on this page. The exact token byte format, signing/certificate mechanics, and the internal message routing are partner-integration details that live in the partner integration guide, not in these consumer-facing docs.