> ## Documentation Index > Fetch the complete documentation index at: https://api-docs.datagol.ai/llms.txt > Use this file to discover all available pages before exploring further. # User Sign Up > ## 1️⃣ Overview **Purpose:** Registers a new user account. Supports two sign-up flows: - **Self Registration** — User registers independently. No hash required. An OTP is sent to the email for verification. - **Workspace Invitation** — User was invited to a workspace via email. The invitation `hash` (received in the invitation email) must be provided along with name and password. --- ## 2️⃣ Endpoint ``` bash POST /idp/api/v1/user/sign-up ``` --- ## 3️⃣ Authentication No authentication required. This is a public endpoint. --- ## 4️⃣ Request Headers | Header | Required | | --- | --- | | Content-Type: application/json | ✅ Yes | --- ## 5️⃣ Request Body Schema ``` json { "email": "string", "password": "string", "firstname": "string", "lastname": "string", "hash": "string" } ``` --- ## 6️⃣ Field Descriptions | Field | Type | Required | Description | | --- | --- | --- | --- | | email | string | ✅ Yes | User's email address | | password | string | ✅ Yes | Min 8 chars, must include uppercase, lowercase, number, and special character | | firstname | string | ✅ Yes | User's first name | | lastname | string | ✅ Yes | User's last name | | hash | string | ⚠️ Conditional | Required only for workspace invitation flow. UUID received in the invitation email. Must be omitted for self-registration. | --- ## 7️⃣ Sign-Up Flows ### 🔵 Self Registration ```json { "email": "user@example.com", "password": "Demo12#$", "firstname": "John", "lastname": "Doe" } ``` - No `hash` required - OTP is sent to the provided email - User must verify email via `/idp/api/v1/user/signUp/verifyEmailOtp` ### 🟢 Workspace Invitation ```json { "email": "user@example.com", "password": "Demo12#$", "firstname": "John", "lastname": "Doe", "hash": "e0754cfc-f7d1-4cc3-8690-e34a2f17291d" } ``` - `hash` is mandatory and must match the one received in the invitation email - User is directly linked to the inviting workspace upon successful registration --- ## 8️⃣ Behavior Summary ``` • Self Registration — OTP is dispatched to the email. Account is pending until OTP is verified. • Workspace Invitation — Hash is validated against the invitation. Account is activated and linked to the workspace. • Password Policy — Enforced for both flows. ``` --- ## 📌 Additional Notes - For self-registration, the OTP verification step is mandatory to activate the account. - For workspace invitation, the `hash` is single-use and time-limited. - `firstname` and `lastname` are required for both flows. ## OpenAPI ````yaml /openapi/openapi.yaml post /idp/api/v1/user/sign-up openapi: 3.0.0 info: title: DataGOL APIs version: 1.0.0 description: '' servers: - url: https://be.datagol.ai - url: https://be.datagol.ai - url: https://kg.datagol.ai - url: https://ai.datagol.ai security: [] tags: - name: Links & Joins description: > ## 🔗 Links & Joins LINK and LOOKUP are special workbook column types that enable relational data modeling across tables. | Column Type | Purpose | |---|---| | `LINK` | Defines a relationship between two tables | | `LOOKUP` | Projects columns from an associated table via a link | Both are configured through `ColumnDTO.colOptions`. A table can have multiple link columns, and each link can have multiple lookup columns. --- ## 📐 UI Data Types - **LINK** — Special column used to represent inter-table relations - **LOOKUP** — Special column used to project associated table fields via a link --- ## 🔗 LINK Semantics A LINK column stores metadata for: - `tableId` — Current table - `associatedTableId` — Associated (linked) table - `relationType` — Type of relationship - `linkColumnId` — Link column identifier **Supported relation patterns:** | Pattern | Description | |---|---| | `ONE_TO_ONE` | Each record in the source maps to one record in the destination | | `ONE_TO_MANY` | One source record maps to many destination records | | `MANY_TO_MANY` | Many source records map to many destination records | --- ## 🔍 LOOKUP Semantics - A LOOKUP column is tightly coupled with a specific LINK column - References a link using `linkColumnId` - Represents a selected column from the associated table - Multiple lookup columns can be defined for the same link --- ## 🗂️ Metadata in `ColumnDTO.colOptions` Use `colOptions` to persist link/lookup metadata. | Field | Description | |---|---| | `columnId` | Current column ID | | `tableId` | Current table ID | | `associatedTableId` | Associated table ID | | `linkColumnId` | Link column ID — used by LOOKUP; references the LINK column's `columnId` | | `relationType` | Relation semantics for LINK | --- ## 🔄 Manual Linking Record Flow To create manual record-level links: 1. Fetch associated table schema/data 2. User selects associated record(s) to link 3. Send linking payload with: - `sourceRecordId` — PK of the current table row - `destinationRecordId` — PK of the associated table row - `linkColumnId` — LINK column identifier 4. Backend resolves link metadata from `linkColumnId` (relation type, associated table, direction/constraints) 5. Backend applies relation rules and stores the link relation --- ## 📋 Record Linking Contract | Field | Description | |---|---| | `sourceRecordId` | PK of the current table row | | `destinationRecordId` | PK of the associated table row | | `linkColumnId` | LINK column identifier | | `tableId` | Current table ID | > Backend derives all remaining relation metadata from the link configuration. --- ## ⚠️ Important Notes > - LINK and LOOKUP are **column-level constructs** first; record linking is a data-level operation built on top > - LOOKUP behavior depends on LINK existence and metadata integrity > - With multiple links to the same associated table, each LOOKUP must bind to the correct `linkColumnId` > - Always treat the associated row ID as the associated table PK for linking UI selection paths: /idp/api/v1/user/sign-up: post: tags: - Sign up summary: User Sign Up description: >- ## 1️⃣ Overview **Purpose:** Registers a new user account. Supports two sign-up flows: - **Self Registration** — User registers independently. No hash required. An OTP is sent to the email for verification. - **Workspace Invitation** — User was invited to a workspace via email. The invitation `hash` (received in the invitation email) must be provided along with name and password. --- ## 2️⃣ Endpoint ``` bash POST /idp/api/v1/user/sign-up ``` --- ## 3️⃣ Authentication No authentication required. This is a public endpoint. --- ## 4️⃣ Request Headers | Header | Required | | --- | --- | | Content-Type: application/json | ✅ Yes | --- ## 5️⃣ Request Body Schema ``` json { "email": "string", "password": "string", "firstname": "string", "lastname": "string", "hash": "string" } ``` --- ## 6️⃣ Field Descriptions | Field | Type | Required | Description | | --- | --- | --- | --- | | email | string | ✅ Yes | User's email address | | password | string | ✅ Yes | Min 8 chars, must include uppercase, lowercase, number, and special character | | firstname | string | ✅ Yes | User's first name | | lastname | string | ✅ Yes | User's last name | | hash | string | ⚠️ Conditional | Required only for workspace invitation flow. UUID received in the invitation email. Must be omitted for self-registration. | --- ## 7️⃣ Sign-Up Flows ### 🔵 Self Registration ```json { "email": "user@example.com", "password": "Demo12#$", "firstname": "John", "lastname": "Doe" } ``` - No `hash` required - OTP is sent to the provided email - User must verify email via `/idp/api/v1/user/signUp/verifyEmailOtp` ### 🟢 Workspace Invitation ```json { "email": "user@example.com", "password": "Demo12#$", "firstname": "John", "lastname": "Doe", "hash": "e0754cfc-f7d1-4cc3-8690-e34a2f17291d" } ``` - `hash` is mandatory and must match the one received in the invitation email - User is directly linked to the inviting workspace upon successful registration --- ## 8️⃣ Behavior Summary ``` • Self Registration — OTP is dispatched to the email. Account is pending until OTP is verified. • Workspace Invitation — Hash is validated against the invitation. Account is activated and linked to the workspace. • Password Policy — Enforced for both flows. ``` --- ## 📌 Additional Notes - For self-registration, the OTP verification step is mandatory to activate the account. - For workspace invitation, the `hash` is single-use and time-limited. - `firstname` and `lastname` are required for both flows. requestBody: required: true content: application/json: schema: type: object required: - email - password - firstname - lastname properties: email: type: string format: email description: User's email address password: type: string format: password description: >- Must include uppercase, lowercase, number, and special character. minLength: 8 firstname: type: string description: User's first name lastname: type: string description: User's last name hash: type: string format: uuid description: >- Invitation hash received in the workspace invitation email. Required only for workspace invitation flow. examples: SelfRegistration: summary: Self Registration (no hash) value: email: demo@abc.com password: PasswordDemo1 firstname: John lastname: Peter WorkspaceInvitation: summary: Workspace Invitation (with hash) value: email: demo@abc.com password: PasswordDemo1 firstname: John lastname: Peter hash: XXXX-XXX-XXXXX responses: '200': description: >- Self Registration: User registered successfully and OTP sent to email. | Workspace Invitation: User registered and linked to the workspace. '400': description: >- Bad Request — Invalid input, missing required fields, or invalid/expired hash '409': description: Conflict — Email already exists '500': description: Internal Server Error ````