> ## 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. # Verify Email OTP for Sign Up > ## 1️⃣ Overview **Purpose:** Verifies the OTP sent to the user's email as the second step of the **self-registration flow**. On successful verification, the user's account is activated. > ⚠️ This endpoint is only applicable for the **Self Registration** flow. Users who signed up via a **Workspace Invitation** (with a hash) do not need to complete this step. --- ## 2️⃣ Endpoint ``` bash POST /idp/api/v1/user/signUp/verifyEmailOtp ``` --- ## 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", "otp": "string" } ``` --- ## 6️⃣ Field Descriptions | Field | Type | Required | Description | | --- | --- | --- | --- | | email | string | ✅ Yes | Must match the email used in the sign-up request | | otp | string | ✅ Yes | One-time password sent to the user's email after sign-up | --- ## 7️⃣ Behavior Summary ``` Second step of the Self Registration flow. • OTP Validation — The OTP must match the one dispatched during sign-up. • Account Activation — On successful verification, the user account is fully activated. • OTP Expiry — OTP is time-limited. If expired, the user must re-initiate the sign-up. • Flow Specific — Only applicable for self-registered users. Invitation-based users are activated immediately upon sign-up. ``` --- ## 📌 Additional Notes - This is **Step 2** of the self-registration flow. Step 1 is `POST /idp/api/v1/user/sign-up`. - The email must exactly match the one used during sign-up. - Workspace invitation users skip this step entirely as their account is activated via hash validation. ## OpenAPI ````yaml /openapi/openapi.yaml post /idp/api/v1/user/signUp/verifyEmailOtp 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/signUp/verifyEmailOtp: post: tags: - Sign up summary: Verify Email OTP for Sign Up description: >- ## 1️⃣ Overview **Purpose:** Verifies the OTP sent to the user's email as the second step of the **self-registration flow**. On successful verification, the user's account is activated. > ⚠️ This endpoint is only applicable for the **Self Registration** flow. Users who signed up via a **Workspace Invitation** (with a hash) do not need to complete this step. --- ## 2️⃣ Endpoint ``` bash POST /idp/api/v1/user/signUp/verifyEmailOtp ``` --- ## 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", "otp": "string" } ``` --- ## 6️⃣ Field Descriptions | Field | Type | Required | Description | | --- | --- | --- | --- | | email | string | ✅ Yes | Must match the email used in the sign-up request | | otp | string | ✅ Yes | One-time password sent to the user's email after sign-up | --- ## 7️⃣ Behavior Summary ``` Second step of the Self Registration flow. • OTP Validation — The OTP must match the one dispatched during sign-up. • Account Activation — On successful verification, the user account is fully activated. • OTP Expiry — OTP is time-limited. If expired, the user must re-initiate the sign-up. • Flow Specific — Only applicable for self-registered users. Invitation-based users are activated immediately upon sign-up. ``` --- ## 📌 Additional Notes - This is **Step 2** of the self-registration flow. Step 1 is `POST /idp/api/v1/user/sign-up`. - The email must exactly match the one used during sign-up. - Workspace invitation users skip this step entirely as their account is activated via hash validation. requestBody: required: true content: application/json: schema: type: object required: - email - otp properties: email: type: string format: email description: User's email address used during sign-up otp: type: string description: One-time password sent to the user's email after sign-up example: '157746' example: email: demo@abc.com otp: '157746' responses: '200': description: OTP verified successfully — account activated '400': description: Bad Request — Invalid or expired OTP '404': description: Not Found — Email not registered '500': description: Internal Server Error ````