1.

Introduction

This document outlines the features of the ShopLinx platform, a social

commerce solution designed to empower businesses with AI-driven
assistance and seamless integrations. Each feature is described with its
scope, technical details, and implementation considerations.

2. Core Features
2.1. Authentication

This section describes the authentication mechanisms for the ShopLinx

platform, covering user signup, login, password management, and API
authentication.

2.1.1. User Signup

 Scope: Allows new users to create accounts on the ShopLinx

platform.

 Methods:

o Google OAuth:

 Leverages Google's OAuth 2.0 authentication flow.

 Users can sign up using their existing Google accounts.

 ShopLinx receives a user's profile information (name,

email, etc.) from Google upon successful authentication.

o Internal Account Creation:

 Users can create accounts directly on ShopLinx using an

email address and password.

 Requires email verification to ensure the user owns the

provided email address.

 Technical Details:

o Google OAuth:

 Utilize a library like firebase-auth or react-google-

login on the frontend (React).

 Backend verifies the Google-issued ID token (google-

auth-library).

o Internal Account Creation:

 Frontend collects user's email and password.

  Backend:

 Validates email format and password strength.

 Hashes the password using a strong hashing

algorithm (bcrypt, Argon2).

 Stores the hashed password in the database.

 Generates a unique verification token.

 Sends a verification email to the user containing

the token.

 Implementation Considerations:

o Password Strength: Enforce strong password policies

(minimum length, special characters, etc.).

o Email Verification: Implement a robust email verification

system to prevent fake accounts.

o Error Handling: Provide clear and informative error messages

for signup failures.

o Rate Limiting: Implement rate limiting to prevent abuse.

2.1.2. User Login

 Scope: Allows existing users to access the ShopLinx platform.

 Methods:

o Email/Password Authentication:

 Users log in using their email address and password.

o Google OAuth Login:

 Users log in using their Google accounts.

 Technical Details:

o Email/Password Authentication:

 Frontend collects user's email and password.

 Backend:

 Retrieves the user's record from the database

based on the email address.

 Compares the provided password with the stored

hashed password.
  If the passwords match, generates a JWT (JSON
Web Token).

o Google OAuth Login:

 Similar to signup, the frontend uses a library to initiate

the Google OAuth flow.

 Backend verifies the Google-issued ID token and

generates a JWT.

 Implementation Considerations:

o Security: Protect against brute-force attacks and credential

stuffing.

o Session Management: Use JWTs for stateless session

management.

o Remember Me: Implement a "remember me" feature using

cookies.

2.1.3. Password Management (Forgot Password)

 Scope: Allows users to reset their passwords if they forget them.

 Process:

i. Request Reset: User requests a password reset by providing

their email address.

ii. Verification Token: The system generates a unique, time-

sensitive reset token and stores it in the database along with
the user's ID and a timestamp.

iii. Email Notification: An email is sent to the user's email

address containing a link with the reset token.

iv. Password Reset: The user clicks the link, which directs them
to a password reset page.

v. Token Validation: The system validates the reset token to

ensure it is valid and hasn't expired.

vi. New Password: The user enters a new password.

vii. Password Update: The system hashes the new password

and updates the user's record in the database. The reset
token is then invalidated or deleted.

 Technical Details:
 o Token Generation: Use a cryptographically secure random
number generator to create reset tokens.

o Token Storage: Store reset tokens in the database with an

expiration timestamp.

o Email Sending: Use a reliable email service (e.g. AWS SES) to

send password reset emails.

 Implementation Considerations:

o Token Expiration: Set a reasonable expiration time for reset

tokens (e.g., 15-30 minutes).

o Security: Protect against token reuse and brute-force attacks.

o User Experience: Provide clear and informative instructions

to the user throughout the password reset process.

2.1.4. API Authentication

 Scope: Secures the ShopLinx API endpoints to ensure that only

authorized users and applications can access them.

 Methods:

o JWT (JSON Web Token):

 The primary method for authenticating API requests.

 Clients include the JWT in the Authorization header of

API requests.

o Custom Header Certification (SHA256 Algorithm):

 An additional layer of security to verify the integrity of

API requests.

 Clients include a custom header with a SHA256 hash of

the request body and other relevant data.

 Technical Details:

o JWT:

 Backend generates a JWT upon successful user login.

 JWT contains user information (user ID, roles, etc.) and

an expiration timestamp.

 API Gateway or backend middleware validates the JWT

before processing the request.
 o Custom Header Certification:

 Client-side:

 Calculates the SHA256 hash of the request body,

timestamp, and a secret key.

 Includes the hash in a custom header (e.g., X-

ShopLinx-Signature).

 Server-side:

 Retrieves the request body, timestamp, and secret

key.

 Calculates the SHA256 hash using the same

algorithm.

 Compares the calculated hash with the hash in the

custom header.

 If the hashes match, the request is considered

valid.

 Implementation Considerations:

o JWT Security: Use a strong secret key to sign JWTs.

o JWT Expiration: Set a reasonable expiration time for JWTs.

o Custom Header Security: Protect the secret key used for

generating the SHA256 hash.

 API Gateway Integration: Use an API Gateway (e.g., AWS API

Gateway) to handle authentication and authorization.

Database Schema :
User:
o _id: ObjectId
o firstName: String (User's first name)
o lastName: String (User's last name)
o languageSetting : String (User app and default language)
o email: String (User's email address, required, unique)
o phoneNumber : String (With country code)
o password: String (Hashed password)
o authPlatforms: { type: [ { method: { type: String, enum:
["local", "apple", "google"], default: null, }, externalUserId:
{ type: String, default: null }, }, ], select: false, }
o organizations: [Object] (Array of organizations the user
belongs to)
 organizationId: ObjectId (Reference to the
Organization document)
  role: String (Role within the organization: "owner",
"admin", "agent")
 businessIds: [ObjectId] (Array of Business IDs the user
has access to, relevant for “owner”,"admin" and
"agent")
o createdAt: Date
o updatedAt: Date

Organization Management :

This section details the features related to managing organizations within

the ShopLinx platform, including trial plan activation, multiple organization
handling, and role-based access control.

1. Trial Plan Activation for New Users

 Scope: Automatically activate a trial plan for new users upon

signup, allowing them to explore the platform's features.

 Process:

i. Signup: When a new user signs up (via Google OAuth or

internal account signup), the system automatically creates a
user profile.

ii. Organization Creation: The user is prompted to create their

first organization.

iii. Trial Plan Assignment: Upon creating their first

organization, the system automatically assigns the trial plan
to that organization.

iv. Feature Access: The organization gains access to the

features included in the trial plan for a limited time (e.g., 14-
30 days).

 Technical Details:

o Database: Store the trial plan assignment in

the Organization table, including the start and end dates of
the trial period.

o Backend Logic: Implement logic to automatically assign the

trial plan upon organization creation.

o Trial Expiration: Implement a mechanism to automatically

disable features upon trial expiration.
 o Frontend Display: Clearly display the trial plan's features
and remaining time to the user.

 Implementation Considerations:

o Trial Plan Definition: Clearly define the features included in

the trial plan.

o Trial Period: Determine the appropriate length of the trial

period (14-30 days).

o Upgrade Prompt: Prompt users to upgrade to a paid plan

before the trial expires.

2. Multiple Organizations with Separate Subscriptions

 Scope: Allow users to create and manage multiple organizations,

each with its own separate subscription plan.

 Process:

i. Organization Creation: Users can create multiple

organizations through the web panel.

ii. Subscription Assignment: Each organization can have its

own subscription plan (trial, basic, premium, etc.).

iii. Billing: Each organization is billed separately based on its

subscription plan.

iv. Feature Access: Each organization has access to the

features included in its subscription plan.

3. Role-Based Access Control (RBAC) for Organizations

 Scope: Implement a role-based access control system to manage

user permissions within each organization.

 Roles:

o Owner: Has full control over the organization, including

managing subscriptions, users, and all business.

o Admin: Can manage teams (agent), settings, and all features

within the business owner has assigned to them as per
organization subscription plan.

o Agent: Has limited access to manage template , campaign

run ,and interact with customers in inbox.

 Process:
 i. Role Assignment: The organization owner can assign roles
to users within the organization.
ii. Permission Enforcement: The system enforces permissions
based on the user's role.

 Technical Details:

o Database: Store user roles in the User or a

separate Organization table, linking users to organizations
and their assigned roles.

o Backend Logic: Implement middleware or decorators to

enforce permissions based on the user's role.

Invited User Flow:

Here's a simplified breakdown of what happens when an invited user

clicks the invitation link, covering both the frontend and backend
processes:

User Clicks Invitation Link (Email)

 The Organization Owner invites a new user (Admin or Agent) and

assigns them to specific businesses. The system generates a unique
invitation link and sends it to the invited user's email address.

 The invited user receives the email and clicks the invitation link.

2. Frontend (React App) - Invitation Link Handling

 Redirection: The invitation link redirects the user to the ShopLinx

web application (app.shoplinx.ai).

 Route Handling: The React Router on the frontend recognizes the

invitation link's structure (e.g., /invite/:invitationToken).

 Component Rendering: A dedicated "Accept Invitation"

component is rendered.

 Check for Authentication:

o Not Authenticated (New User): If the user is not logged in,

the component displays a signup/login form with a message
like "Please create an account or log in to accept the
invitation."

o Authenticated (Existing User): If the user is already logged

in, the component proceeds to the next step.
  Form Submission (if new user):

o The user fills out the signup form (or logs in).

o The frontend sends a request to the backend (API) with the

signup/login credentials and the invitationToken.

 Data Handling: The frontend doesn't directly validate

the invitationToken. It simply passes it to the backend for
processing.

 Loading State: Display a loading indicator while waiting for the

backend response.

 Success/Error Handling: Display appropriate messages to the

user based on the backend response (e.g., "Invitation accepted
successfully!" or "Invalid invitation token.").

3. Backend (API) - Invitation Processing

 API Endpoint: The frontend sends a request to a specific API

endpoint (e.g., POST /api/accept-invitation).

 Authentication (if required): If the user is logging in, the backend

authenticates the user's credentials.

 Invitation Token Validation:

o The backend receives the invitationToken from the frontend.

o It queries the Invitations table in the database to find a

matching record.

o It performs the following validations:

 Token Exists: Is there an invitation with this token?

 Not Expired: Has the invitation expired (based on the

expiration timestamp)?

 Not Accepted: Has the invitation already been

accepted?

 User Association:

o If the token is valid:

 The backend retrieves the Organization ID, assigned

Role, and assigned Business ID(s) from
the Invitations table.
  It creates a new user account (if the user is new) or
updates the existing user account.

 It associates the user with the organization, assigns the

specified role, and grants access to the assigned
businesses.

 It updates the Invitations table to mark the invitation as

"Accepted."

 Response:

o Success: The backend sends a success response to the

frontend, typically including a JWT for the newly
created/logged-in user.

o Error: If the token is invalid or any other error occurs, the

backend sends an error response with an appropriate error
message.

 Database Schema :

Organization:

o _id: ObjectId (MongoDB's unique identifier)

o name: String (Name of the organization, required)
o description: String (Optional description of the organization)
o ownerId: ObjectId (Reference to the User who created the
organization, required)
o subscription: Object
 planId: ObjectId (Reference to the Subscription Plan,
required)
 startDate: Date (Subscription start date)
 endDate: Date (Subscription end date)
 status: String (e.g., "active", "trial", "expired",
"cancelled")
 paymentDetails: Object (Details about the payment
method, transaction ID, etc.)
o businesses: [ObjectId] (Array of references to Business
documents associated with the organization)
o teams: [ObjectId] (Array of references to Team documents
associated with the organization)
o createdAt: Date (Timestamp of when the organization was
created)
 o updatedAt: Date (Timestamp of when the organization was last
updated)

Subscription Plan:

o _id: ObjectId
o name: String (Name of the plan, e.g., "Trial", "Starter",
"Growth", "Enterprise")

o description: String (Description of the plan)

o price: Number (Price of the plan)

o features: Object (Limits and features included in the

plan)

o maxBusinesses: Number (Maximum number of businesses

allowed)

o maxContacts: Number (Maximum number of contacts

allowed)

o knowledgeBaseAccess: Boolean (Access to create and

manage knowledge base)

o knowledgeBaseLimit: Number (Limit on the number of

documents/entries in the knowledge base)

o facebookInstagramIntegration: Boolean

o whatsAppIntegration: Boolean

o catalogWebsite: Boolean

o shopifyIntegration: Boolean

o virtualSalesAssistant: Boolean (Overall access to

Virtual Sales Assistant)

o inventoryAssistance: Boolean (Access to Inventory

Assistance)

o financeAssistance: Boolean (Access to Finance

Assistance (future))

o customDomain: Boolean

o aiAssistance: Boolean (General AI Assistance)

o whatsAppAutomation: Boolean (Access to WhatsApp

Automation features)

o instagramAutomation: Boolean (Access to Instagram

Automation features)
 o facebookAutomation: Boolean (Access to Facebook
Automation features)

o workflowBuilder: Boolean (Access to the Workflow

Builder for automations)

o multipleBusinessUnits: Boolean

o organizationalStructureSupport: Boolean

o billingCycle: String (e.g., "monthly", "yearly")

Invitation Model :
o _id: MongoDB's unique identifier for the invitation
document.

o organizationId: A reference to the Organization document to

which the invited user will be added.

o invitedBy: A reference to the User document of the user who

sent the invitation (the Organization Owner).

o invitedEmail: The email address of the person being

invited. This is crucial for sending the invitation and
associating the user with the organization upon
signup/login.

o role: The role the invited user will have within the
organization ("admin" or "agent").

o businessIds: An array of ObjectIds referencing

the Business documents that the invited user will have
access to.

o invitationToken: A unique, randomly generated string used

to verify the invitation when the user clicks the link.

o expiresAt: A timestamp indicating when the invitation

expires. This is important for security reasons.

o status: The current status of the invitation. Possible

values:

o "pending": The invitation has been sent but not yet

accepted.

o "accepted": The invitation has been accepted, and the

user has been added to the organization.

o "expired": The invitation has expired and can no

longer be used.
 o createdAt: The timestamp when the invitation was created.

o updatedAt: The timestamp when the invitation was last

updated.

Organization Dashboard and Business Setup

This section details the design and functionality of the Organization

Dashboard, specifically focusing on the initial Business setup process,
including information collection, store settings, integration settings, and
payment gateway setup.

1. Organization Dashboard Overview

 Scope: The Organization Dashboard is the central hub for managing

an organization and its associated businesses.

 Access: After a user selects an organization, they are directed to

the Organization Dashboard.

 Content:

o Welcome Message: A personalized welcome message to the

user.

o Business List:

 Displays a list of all businesses associated with the

organization.

 If no businesses exist, displays a prominent call to action

to "Set Up Your First Business."

 For existing businesses, displays:

 Business Name

 Business Logo (if available)

 Status indicators (e.g., "Active," "Inactive," "Needs

Setup")

 Links to:

 Access the Business Store Panel

 Manage Business Settings

o Organization Settings:

 Link to manage organization-level settings (e.g.,

subscription, team members).
 o Help/Support:

 Links to documentation, FAQs, and support resources.

2. Business Setup Process

 Scope: Guides the user through the process of setting up a new

business within the organization.

 Trigger: Initiated by clicking the "Set Up Your First Business" button

(if no businesses exist) or a "Add New Business" button.

 Multi-Step Form: The setup process is presented as a multi-step

form to make it more manageable.

Step 1: Basic Business Information

 Fields:

o Business Category: (Dropdown with predefined categories,

e.g., "Textile," "Restaurant," "Retail")

o Business Subcategory: (Dropdown, dynamically populated

based on the selected category)

o Business Name: (Text input, required)

o Business Username: (Text input, used for the default

subdomain, auto-generated from the Business Name, can be
edited, must be unique)

o Business Logo: (Image upload)

o Business QR Code: (Automatically generated based on the

Business Store URL, downloadable)

o Address: (Text input, multi-line)

o Website: (URL input, optional)

o Business Email: (Email input, optional)

o Phone Number: (Phone number input with country code,

optional)

o Description: (Text area, optional)

 Validation:

o Business Name is required.

o Business Username must be unique.

o Email and Website should be validated for correct format.

  Action: "Next" button to proceed to the next step.

Step 2: Business Store Settings

 Content:

o Default Business Store URL: (Display only, based on the

Business Username, e.g., kaneeztextile.shoplinx.ai)

o Custom Domain Settings:

 Option to "Connect a Custom Domain" (toggle).

 If enabled:

 Custom Domain Input (URL input).

 Instructions on how to configure DNS settings (A

record, CNAME record).

o Theme Settings:

 Theme Selection: (Display available themes as

thumbnails).

 Color Customization: (Color pickers for primary and

secondary colors).

 Action: "Next" button to proceed to the next step.

Step 3: Integration Settings

 Content:

o Displays a list of available integrations (Facebook, WhatsApp,

Instagram, Shopify, etc.).

o For each integration:

 Status Indicator (Connected/Not Connected).

 "Connect" button (if not connected).

 "Manage" button (if connected).

 Brief description of the integration.

 Action: Clicking "Connect" or "Manage" redirects the user to the

specific integration settings page (discussed below).

 Note: This step provides an overview and links to individual

integration settings. The actual integration configuration happens
on separate pages.

Step 4: Payment Gateway Setup

  Content:

o Displays a list of available payment gateways (e.g., Razorpay,

Stripe, PayPal).

o For each payment gateway:

 Status Indicator (Connected/Not Connected).

 "Connect" button (if not connected).

 Brief description of the payment gateway.

 Razorpay Example:

o If the user selects Razorpay and clicks "Connect":

 Displays a form to collect the required information:

 Key ID

 Key Secret

 Webhook URL (automatically generated by the

system, displayed to the user with instructions on
how to configure it in Razorpay)

 "Save" button to save the Razorpay settings.

 Validation:

o Key ID and Key Secret are required.

 Action: "Finish" button to complete the Business setup process.

3. Integration Settings Pages (Example: WhatsApp)

 Access: Accessed by clicking "Connect" or "Manage" on the

Integration Settings step.

 Content:

o Connection Status: Displays the current connection status

(Connected/Not Connected).

o WhatsApp Business Account Details:

 Business Account ID

 Phone Number ID

 Access Token

o WhatsApp Business Profile:

  Fields to manage the WhatsApp Business profile (Name,
About, Profile Picture).

o WhatsApp Business API Status:

 Quality Rating

 Remaining Quota

 Verification Status

o Automation Settings:

 Links to configure WhatsApp automation rules (auto-

replies, welcome messages).

4. Completion and Redirection

 Upon clicking "Finish" on the Payment Gateway Setup step:

o The system saves all the collected business information to

the Business model in the database.

o The user is redirected back to the Organization Dashboard.

o The newly created business is displayed in the Business List

with a status of "Active."

Key Considerations

 User Experience: Design the setup process to be as intuitive and

user-friendly as possible.

 Validation: Implement robust validation to ensure data quality.

 Error Handling: Provide clear and informative error messages.

 Security: Securely store sensitive information like API keys and

access tokens.

 Scalability: Design the system to handle a large number of

businesses and integrations.

This detailed breakdown should give you a comprehensive understanding

of how to manage the Organization Dashboard and the Business setup
process. Let me know if you have any further questions!

ShopLinx Data Model Documentation

1. Business Model
Purpose:
The Business model stores core information about each business using the
ShopLinx platform. It includes basic details, contact information, and
references to integration settings.

Business Model

o _id: ObjectId (MongoDB's unique identifier)

o organizationId: ObjectId (Reference to the Organization document)

o name: String (Name of the business)

o description: String (Optional description)

o logo: String (URL to the business logo)

o qrCode: String (URL or data for the generated QR code)

o category: String (Business category)

o subcategory: String (Business subcategory)

o address: String (Business address)

o websiteUrl: String (URL to the business's external website)

o contactEmail: String (Contact email)

o contactPhone: String (Contact phone number)

o catalogueStore: ObjectId (Reference to the Catalogue document)

o whatsappIntegrationId: ObjectId (Reference to WhatsAppIntegration

document)

o facebookIntegrationId: ObjectId (Reference to FacebookIntegration

document)

o instagramIntegrationId: ObjectId (Reference to InstagramIntegration

document)

o shopifyIntegrationId: ObjectId (Reference to ShopifyIntegration

document)

o paymentIntegrationId: ObjectId (Reference to PaymentIntegration

document)

o createdAt: Date (Timestamp of when the business was created)

o updatedAt: Date (Timestamp of when the business was last updated)

Relationships:

 organizationId: References the Organization model, indicating which

organization the business belongs to.

 catalogueStore: References the Catalogue model, linking the

business to its product catalog.

 whatsappIntegrationId: References the WhatsAppIntegration model,

storing detailed WhatsApp settings.

 facebookIntegrationId: References the FacebookIntegration model,

storing detailed Facebook settings.

 instagramIntegrationId: References the InstagramIntegration model,

storing detailed Instagram settings.

 shopifyIntegrationId: References the ShopifyIntegration model,

storing detailed Shopify settings.

 paymentIntegrationId: References the PaymentIntegration model,

storing detailed payment gateway settings.

2. WhatsAppIntegration Model

Purpose:
The WhatsAppIntegration model stores detailed settings and
configurations for integrating a business with the WhatsApp Business API.

WhatsAppIntegration Model

 _id: ObjectId (MongoDB's unique identifier)

 businessId: ObjectId (Reference to the Business document)

 isConnected: Boolean (Indicates if WhatsApp is connected)

 businessAccountId: String (WhatsApp Business Account ID)

 phoneNumberId: String (Phone number ID for WhatsApp)

 accessToken: String (Access token for WhatsApp Business API)

 profile: Object

o name: String

o about: String

o profilePictureUrl: String

 apiStatus: Object

o qualityRating: String (e.g., "Green", "Yellow", "Red")

 o remainingQuota: Number (Number of messages remaining)

o isVerified: Boolean (Is the business account verified?)

 automation: Object

o enabled: Boolean (Overall toggle for WhatsApp automation)

o welcomeMessage: String (Welcome message for new users)

o awayMessage: String (Away message when the business is

unavailable)

o keywordResponses: Array

 keyword: String

 response: String

o workflowBuilder: Object

 enabled: Boolean

 workflowId: ObjectId (Reference to a Workflow

document)

o templateManager: Object

 enabled: Boolean

 templateIds: [ObjectId] (Reference to Template

documents)

o campaignManager: Object

 enabled: Boolean

 campaignIds: [ObjectId] (Reference to Campaign

documents)

 createdAt: Date (Timestamp of when the WhatsApp integration

document was created)

 updatedAt: Date (Timestamp of when the WhatsApp integration

document was last updated)

Relationships:

 businessId: References the Business model, indicating which

business the WhatsApp integration belongs to.
  automation.workflowBuilder.workflowId: References
the Workflow model, linking to a specific workflow.

 automation.templateManager.templateIds: References
the Template model, linking to specific message templates.

 automation.campaignManager.campaignIds: References
the Campaign model, linking to specific campaigns.

3. FacebookIntegration Model

Purpose:
The FacebookIntegration model stores settings for integrating a business
with its Facebook Page.

FacebookIntegration Model

 _id: ObjectId (MongoDB's unique identifier)

 businessId: ObjectId (Reference to the Business document)

 isConnected: Boolean (Indicates if Facebook is connected)

 pageId: String (Facebook Page ID)

 accessToken: String (Access token for Facebook)

 automation: Object

o enabled: Boolean (Overall toggle for Facebook automation)

o welcomeMessage: String (Welcome message for new users)

o keywordResponses: Array

 keyword: String

 response: String

 createdAt: Date (Timestamp of when the Facebook integration

document was created)

 updatedAt: Date (Timestamp of when the Facebook integration

document was last updated)

Relationships:

 businessId: References the Business model, indicating which

business the Facebook integration belongs to.

4. InstagramIntegration Model
Purpose:
The InstagramIntegration model stores settings for integrating a business
with its Instagram Business Account.

InstagramIntegration Model

 _id: ObjectId (MongoDB's unique identifier)

 businessId: ObjectId (Reference to the Business document)

 isConnected: Boolean (Indicates if Instagram is connected)

 accountId: String (Instagram Business Account ID)

 accessToken: String (Access token for Instagram)

 automation: Object

o enabled: Boolean (Overall toggle for Instagram automation)

o welcomeMessage: String (Welcome message for new

followers)

o storyReply: String (Automated reply to story mentions)

 createdAt: Date (Timestamp of when the Instagram integration

document was created)

 updatedAt: Date (Timestamp of when the Instagram integration

document was last updated)

Relationships:

 businessId: References the Business model, indicating which

business the Instagram integration belongs to.

5. ShopifyIntegration Model

Purpose:
The ShopifyIntegration model stores settings for integrating a business
with its Shopify store.

ShopifyIntegration Model

 _id: ObjectId (MongoDB's unique identifier)

 businessId: ObjectId (Reference to the Business document)

 isConnected: Boolean (Indicates if Shopify is connected)

 storeUrl: String (Shopify store URL)

 accessToken: String (Access token for Shopify)

  createdAt: Date (Timestamp of when the Shopify integration
document was created)

 updatedAt: Date (Timestamp of when the Shopify integration

document was last updated)

Relationships:

 businessId: References the Business model, indicating which

business the Shopify integration belongs to.

6. PaymentIntegration Model

Purpose:
The PaymentIntegration model stores settings for integrating a business
with various payment gateways.

PaymentIntegration Model

 _id: ObjectId (MongoDB's unique identifier)

 businessId: ObjectId (Reference to the Business document)

 razorpay: Object

o isConnected: Boolean (Indicates if Razorpay is connected)

o keyId: String (Razorpay Key ID)

o keySecret: String (Razorpay Key Secret)

o webhookUrl: String (Webhook URL for Razorpay)

 stripe: Object

o isConnected: Boolean (Indicates if Stripe is connected)

o // Stripe-specific settings

 paypal: Object

o isConnected: Boolean (Indicates if PayPal is connected)

o // PayPal-specific settings

 createdAt: Date (Timestamp of when the Payment integration

document was created)

 updatedAt: Date (Timestamp of when the Payment integration

document was last updated)
Relationships:

 businessId: References the Business model, indicating which

business the payment integration belongs to.

6. CatalogueStore Model

The CatalogueStore model is designed to manage the settings and

configurations for the online store or catalogue associated with a
business. This includes visual customization, chatbot settings, and
product/category display management.

CatalogueStore Model

 _id: ObjectId (MongoDB's unique identifier)

 businessId: ObjectId (Reference to the associated Business

document)

 theme: String (The selected theme for the store, e.g., "default",
"modern", "classic")

 customColor: String (Custom color code for the store, e.g., hex code
like "#FF5733")

 subdomain: String (Subdomain for the store, e.g.,

"mystore.shoplinx.com")

 storeName: String (Name of the store as displayed to customers)

 storeDescription: String (Description of the store for customers)

 logo: String (URL to the store's logo image)

 favicon: String (URL to the store's favicon image)

 chatbotSettings: Object

o enabled: Boolean (Indicates if the chatbot is enabled for the

store)

o welcomeMessage: String (Welcome message displayed by the

chatbot)

o responses: Array

 keyword: String (Keyword to trigger the response)

 response: String (Automated response to the keyword)

 o customization: Object

 color: String (Custom color for the chatbot interface)

 position: String (Position of the chatbot on the store

page, e.g., "bottom-right")

 displaySettings: Object

o displayMode: String (Determines whether to display products,

categories, or both, e.g., "products", "categories", "both")

o selectedProducts: [ObjectId] (Array of references to Product

documents to display)

o selectedCategories: [ObjectId] (Array of references to

Category documents to display)

 createdAt: Date (Timestamp of when the catalogue store was

created)

 updatedAt: Date (Timestamp of when the catalogue store was last

updated)

Example Document

Here’s an example of how a CatalogueStore document might look:

"_id": ObjectId("60d5ec49f1a2c8b1f8e4e1a1"),

"businessId": ObjectId("60d5ec49f1a2c8b1f8e4e1a0"),

"theme": "modern",

"customColor": "#FF5733",

"subdomain": "mystore.shoplinx.com",

"storeName": "My Awesome Store",

"storeDescription": "The best place to find awesome products!",

"logo": "https://example.com/logo.png",

"favicon": "https://example.com/favicon.ico",

"chatbotSettings": {

"enabled": true,
 "welcomeMessage": "Hello! How can I assist you today?",

"responses": [

"keyword": "shipping",

"response": "We offer free shipping on orders over $50!"

},

"keyword": "return policy",

"response": "You can return any item within 30 days for a full refund."

],

"customization": {

"color": "#4CAF50",

"position": "bottom-right"

},

"displaySettings": {

"displayMode": "both",

"selectedProducts": [

ObjectId("60d5ec49f1a2c8b1f8e4e200"),

ObjectId("60d5ec49f1a2c8b1f8e4e201")

],

"selectedCategories": [

ObjectId("60d5ec49f1a2c8b1f8e4e210")

},

"createdAt": ISODate("2025-03-02T12:00:00Z"),

"updatedAt": ISODate("2025-03-02T12:00:00Z")

}
The CatalogueStore model provides a comprehensive framework for
managing online store settings, including product and category display
options, chatbot integration, and visual customization. This structured
approach allows businesses to create a personalized shopping experience
for their customers while maintaining flexibility in customization.