MindbricksProject

MPO Version: 1.3.0

MindbricksProject is the root class representing the entire architecture of a software project in Mindbricks. It sits at the top of the Mindbricks ontology tree—a structured, semantic pattern definition scheme used to model projects. Mindbricks leverages this ontology to generate microservice-based applications by interpreting and compiling interconnected pattern objects. Each pattern object is defined as a class with typed properties, which can include both primitive types and references to other pattern classes. Projects are built as JSON instances that follow this schema, enabling AI agents and human architects to collaboratively define a system's structure, behavior, and deployment blueprint in a unified and machine-readable format.

interface MindbricksProject = {
  projectSettings : ProjectSettings;
  authentication : ProjectAuthentication;
  bffService : BFFService;
  notificationService : NotificationService;
  services : Service[];
}

ProjectSettings

MPO Version: 1.3.0

Defines the core configuration of your Mindbricks project, including metadata, environment preferences, and infrastructure integrations. Use this section to set up the project name, description, and optionally override managed infrastructure services with your own. While Mindbricks provides managed services by default to ensure a reliable, production-ready architecture, you may choose to integrate custom services for Redis, PostgreSQL, Kafka, and others as needed.

interface ProjectSettings = {
  basicSettings : BasicProjectSettings;
  stripeSettings : StripeSettings;
  aiSettings : AiSettings;
  corsSettings : CorsSettings;
  pipelineTemplates : PipelineTemplate[];
  integrations : IntegrationConfiguration[];
}

BasicProjectSettings

MPO Version: 1.3.0

Defines the basic settings of your Mindbricks project, including its identity, descriptive metadata, environment variables, and current lifecycle stage. These values are essential for naming, documentation, and runtime configuration.

interface BasicProjectSettings = {
  name : String;
  fullname : String;
  description : Text;
  avatar : String;
  frontendDocument : Text;
  hasAuthentication : Boolean;
  ignoreDeploymentSpecificFiles : Boolean;
  customVariables : DataMapSimpleItem[];
}

DataMapSimpleItem

MPO Version: 1.3.0

Represents a single key-value pair used in most context. The value is constant.

interface DataMapSimpleItem = {
  name : String;
  value : String;
}

StripeSettings

MPO Version: 1.3.0

Defines integration settings for Stripe payments. Mindbricks does not provide a managed Stripe account—keys for both test and live modes must be supplied manually.

interface StripeSettings = {
  useStripe : Boolean;
  configuration : StripeSettingsConfig;
}

StripeSettingsConfig

MPO Version: 1.3.0

Defines the configuration for Stripe. This object is used when useStripe is set to true. It includes API keys for both test and live modes.

interface StripeSettingsConfig = {
  testPublicKey : String;
  testSecretKey : String;
  livePublicKey : String;
  liveSecretKey : String;
}

AiSettings

MPO Version: 1.3.0

Defines API keys for AI service providers such as OpenAI and Anthropic. These keys are used in any AI-powered logic within the application.

interface AiSettings = {
  openAiApiKey : String;
  anthropicApiKey : String;
}

CorsSettings

MPO Version: 1.3.0

Defines CORS settings for service accesses. When enabled Cross Origins will be accepted according to the settings.

interface CorsSettings = {
  useCorsControl : Boolean;
  configuration : CorsSettingsConfig;
}

CorsSettingsConfig

MPO Version: 1.3.0

Defines the configuration for CORS settings. This object is used when useCorsControl is set to true. Note that if your service is in a different subdomain, Mindbricks automatically uses wildcard url control and allows other subdomains in the same main domain. Localhost Vite ports are also allowed automatically.

interface CorsSettingsConfig = {
  allowedOrigins : String[];
  allowAllSubdomains : Boolean;
}

PipelineTemplate

MPO Version: 1.3.0

The asset to store a template for generating custom pipeline files. Used in project level and applied to all microservices.

interface PipelineTemplate = {
  filename : String;
  template : Text;
}

IntegrationConfiguration

MPO Version: 1.3.0

A configuration class to define client parameters to use a remote API like AWS S3, Twillio or any other 3rd part api provider.

interface IntegrationConfiguration = {
  provider : IntegrationProvider;
  configuration : DataMapItem[];
}

IntegrationProvider

An Enum vaue to store the names of the integration providers

IntegrationProviderNames = [
  "amazonS3",
  "googleGemini",
  "googleMaps",
  "Telegram",
];

const IntegrationProvider = {
  amazonS3: 0,
  googleGemini: 1,
  googleMaps: 2,
  Telegram: 3,
};

DataMapItem

MPO Version: 1.3.0

Represents a single key-value pair used in most context. The value can be defined dynamically using an MScript.

interface DataMapItem = {
  name : String;
  value : MScript;
}

MScript

MPO Version: 1.3.0

Represents a Mindbricks JavaScript expression used for logic, validation, or configuration. An MScript is stored as a string in the JSON schema but is expected to conform to a valid JavaScript ExpressionStatement. Acceptable forms include literals, identifiers, expressions, function calls, or a module.exports assignment returning a valid object. Although stored as plain text, MScripts are parsed and analyzed using a specialized override class that allows static checks and evaluation.

interface MScript = {
}

ProjectAuthentication

MPO Version: 1.3.0

Defines the authentication and authorization configuration for the entire project. This module serves as the foundation for user identity, login behavior, access control, and verification flows. All services in the project, especially user services, rely on these centralized settings.

interface ProjectAuthentication = {
  authenticationEssentials : AuthBasics;
  loginDefinition : LoginDefinition;
  verificationServices : VerificationServices;
  accessControl : AccessControl;
  socialLogins : SocialLoginSettings;
  userProperties : DataProperty[];
  tenantProperties : DataProperty[];
}

AuthBasics

MPO Version: 1.3.0

Defines the fundamental authentication configuration for the project. These settings determine the authentication method(s) used across all services, including token-based, SSO, remote service, or API key authentication.

interface AuthBasics = {
  JWTAuthentication : JWTAuth;
  ssoAuthentication : SSOAuth;
  apiKeyAuthentication : APIKeyAuth;
  httpSettings : AuthHttpSettings;
  cookieSettings : CookieSettings;
}

JWTAuth

MPO Version: 1.3.0

Defines the configuration for JWT-based authentication, where the project issues and verifies its own JSON Web Tokens. This is the recommended authentication method in Mindbricks due to its stateless nature and scalability.

interface JWTAuth = {
  useJWTForAuthentication : Boolean;
  configuration : JWTAuthConfig;
}

JWTAuthConfig

MPO Version: 1.3.0

Defines the configuration details for JWT-based authentication. This object is used when useJWTForAuthentication is set to true. It includes token and key refresh periods.

interface JWTAuthConfig = {
  tokenPeriodInDays : Integer;
  keyRefreshPeriodInDays : Integer;
}

SSOAuth

MPO Version: 1.3.0

Defines the Single Sign-On (SSO) configuration for the project. This allows users to authenticate via their organization's identity provider using standard SSO protocols. Mindbricks integrates with external SSO providers but does not generate or host its own SSO server.

interface SSOAuth = {
  useSSOForAuthentication : Boolean;
  configuration : SSOAuthConfig;
}

SSOAuthConfig

MPO Version: 1.3.0

Defines the configuration for an external SSO provider. This object is used when useSSOForAuthentication is set to true. It includes provider name, token period, endpoints, and profile mapping.

interface SSOAuthConfig = {
  ssoName : String;
  tokenPeriodInMinutes : Integer;
  emailPropertyInProfile : String;
  userNamePropertyInProfile : String;
  ssoUserIdPropertyInProfile : String;
  ssoServerSettings : SSOServerSettings;
}

SSOServerSettings

MPO Version: 1.3.0

The SSOServerSettings object defines the configuration for a Single Sign-On (SSO) integration, including endpoint URLs and client credentials. These settings enable the service to interact with an external identity provider using OAuth2/OIDC protocols by specifying how to authenticate, retrieve tokens, get user info, and handle logouts.

interface SSOServerSettings = {
  tokenHost : String;
  authPath : String;
  tokenPath : String;
  userInfoPath : String;
  logoutPath : String;
  redirectUrl : String;
  clientId : String;
  clientSecret : String;
}

APIKeyAuth

MPO Version: 1.3.0

Defines the configuration for API key-based authentication. This method allows clients to authenticate by providing a public API key and an optional secret in the request. It can be used as the primary or a supplemental authentication method.

interface APIKeyAuth = {
  useAPIKeyForAuthentication : Boolean;
  configuration : APIKeyAuthConfig;
}

APIKeyAuthConfig

MPO Version: 1.3.0

Configuration details for API key authentication, including key and secret names and their locations.

interface APIKeyAuthConfig = {
  apiKeyLocation : RequestLocations;
  apiKeyName : String;
  apiSecretName : String;
}

RequestLocations

An enum type to refer to a specific section of an HTTP request where data (e.g., tokens or parameters) can be located.

RequestLocationsNames = [
  "bearer",
  "cookie",
  "header",
  "query",
  "body",
  "urlpath",
  "session",
  "request",
];

const RequestLocations = {
  bearer: 0,
  cookie: 1,
  header: 2,
  query: 3,
  body: 4,
  urlpath: 5,
  session: 6,
  request: 7,
};

AuthHttpSettings

MPO Version: 1.3.0

Defines the HTTP configuration of the auth service. Primarily includes the port on which the auth service will accept HTTP requests.

interface AuthHttpSettings = {
  httpPort : Integer;
  routerSuffix : String;
}

CookieSettings

MPO Version: 1.3.0

Use this settings to arrange the allowed domains of your applications cookie. Note thar a mindbricks service cookie is set as secure:true, httpOnly:true, sameSite:none, but domain is set according to the login requesrt hos if it is in. the allowed list or defaults.

interface CookieSettings = {
  allowedDomains : String[];
}

LoginDefinition

MPO Version: 1.3.0

Defines the core login architecture of the project, including the user and tenant structures that underpin authentication and access. These settings enable Mindbricks to generate a built-in 'auth' service tailored to your data model, supporting user registration, login, permissions, and optional multi-tenant behavior.

interface LoginDefinition = {
  userSettings : LoginDefUserSettings;
  tenantSettings : LoginDefTenantSettings;
}

LoginDefUserSettings

MPO Version: 1.3.0

Defines how users are stored, managed, and authenticated within the project. This includes super admin credentials, login identifiers, optional mobile and email verification settings, public registration policies, and whether user groups are active. This structure governs the behavior and structure of the user service's primary data model.

interface LoginDefUserSettings = {
  superAdminEmail : String;
  superAdminPassword : String;
  userNameType : UserNameType;
  superAdminData : DataMapItem[];
  userGroupsActive : Boolean;
  userGroupsInTenantLevel : Boolean;
  userMobileIsActive : Boolean;
  emailVerificationRequiredForLogin : Boolean;
  mobileVerificationRequiredForLogin : Boolean;
  mobile2FARequiredForLogin : Boolean;
  email2FARequiredForLogin : Boolean;
  userRegisterIsPublic : Boolean;
  userAutoAvatarScript : MScript;
  userGroupAutoAvatarScript : MScript;
}

UserNameType

Specifies how user names are represented in the data model.

UserNameTypeNames = ["asFullname", "asNamePair"];

const UserNameType = {
  asFullname: 0,
  asNamePair: 1,
};

LoginDefTenantSettings

MPO Version: 1.3.0

Specifies how tenant-based access control is structured for multi-tenant projects. This includes the tenant object name, registration permissions, and tenant separation logic. When enabled, this enforces strict data and user isolation by tenant.

interface LoginDefTenantSettings = {
  useMultiTenantFeature : Boolean;
  configuration : LoginDefTenantSettingsConfig;
}

LoginDefTenantSettingsConfig

MPO Version: 1.3.0

Configuration details for tenant-based access control, including tenant registration, naming, and avatar script.

interface LoginDefTenantSettingsConfig = {
  tenantRegisterIsPublic : Boolean;
  tenantName : String;
  tenantAutoAvatarScript : MScript;
}

VerificationServices

MPO Version: 1.3.0

Defines user-related verification features such as password resets and two-factor authentication (2FA). Mindbricks generates backend support code for these features automatically, based on this configuration, as part of the user service module.

interface VerificationServices = {
  verificationSettings : VerificationSettings;
  passwordResetByEmail : PasswordResetByEmail;
  passwordResetByMobile : PasswordResetByMobile;
  email2Factor : Email2Factor;
  mobile2Factor : Mobile2Factor;
  emailVerification : EmailVerification;
  mobileVerification : MobileVerification;
}

VerificationSettings

MPO Version: 1.3.0

General options for all verifications. You can change the verification mode (test/live) here.

interface VerificationSettings = {
  verificationMode : VerificationMode;
}

VerificationMode

An enum value to define the verification mode of the verification services to be able to manage the development process and the production process.

VerificationModeNames = ["testMode", "liveMode"];

const VerificationMode = {
  testMode: 0,
  liveMode: 1,
};

PasswordResetByEmail

MPO Version: 1.3.0

Configuration for enabling password reset via email. Defines whether the feature is active, how long the reset token remains valid, and how frequently a user can request resending the verification message.

interface PasswordResetByEmail = {
  passwordResetByEmailIsActive : Boolean;
  configuration : VerificationConfig;
}

VerificationConfig

MPO Version: 1.3.0

Defines the configuration for verification flows, including password resets and two-factor authentication. This object is used when the respective feature is active.

interface VerificationConfig = {
  resendTimeWindow : Integer;
  expireTimeWindow : Integer;
  verificationType : VerificationType;
  verificationTemplate : Text;
}

VerificationType

Defines the method used for user verification flows such as password reset, two-factor authentication, or account confirmation. This enum helps determine whether the user interacts with a clickable link or a manually entered code.

VerificationTypeNames = ["byLink", "byCode"];

const VerificationType = {
  byLink: 0,
  byCode: 1,
};

PasswordResetByMobile

MPO Version: 1.3.0

Configuration for enabling password reset via mobile. Specifies token expiration time, resend intervals, and verification type (link or code).

interface PasswordResetByMobile = {
  passwordResetByMobileIsActive : Boolean;
  configuration : VerificationConfig;
}

Email2Factor

MPO Version: 1.3.0

Configuration for email-based two-factor authentication. Activates the feature and defines verification expiration and resend rules.

interface Email2Factor = {
  email2FactorIsActive : Boolean;
  configuration : VerificationConfig;
}

Mobile2Factor

MPO Version: 1.3.0

Configuration for mobile-based two-factor authentication. Allows setup of token validity duration, resend rate, and type of verification mechanism.

interface Mobile2Factor = {
  mobile2FactorIsActive : Boolean;
  configuration : VerificationConfig;
}

EmailVerification

MPO Version: 1.3.0

Defines the settings for verifying a user's email address. Includes token expiration duration, resend interval, and whether verification is handled via link or code.

interface EmailVerification = {
  emailVerificationIsActive : Boolean;
  configuration : VerificationConfig;
}

MobileVerification

MPO Version: 1.3.0

Defines the settings for verifying a user's mobile number. Includes resend interval, expiration period, and verification method (link or code).

interface MobileVerification = {
  mobileVerificationIsActive : Boolean;
  configuration : VerificationConfig;
}

AccessControl

MPO Version: 1.3.0

Configuration chapter for defining the access control architecture of the project. Mindbricks supports multiple authorization models including role-based, user-based, object-based, and attribute-based access controls. This section enables a unified, flexible, and scalable permission system that ensures resources and operations are securely accessed based on defined authorization rules across services.

interface AccessControl = {
  permissionBasics : PermissionBasics;
  roleSettings : RBACSettings;
  permissionTypes : PermissionTypes;
  objectBasedSettings : OBACPermission;
  attributeBasedSettings : AbacPermission;
}

PermissionBasics

MPO Version: 1.3.0

Defines the foundational permission model of the project. This section enables Permission-Based Access Control (PBAC) by allowing the architect to organize granular permissions into named groups. These permission groups act as the reference set for roles, users, and object-level rules throughout the project.

interface PermissionBasics = {
  pbacIsActive : Boolean;
  configuration : PermissionBasicsConfig;
}

PermissionBasicsConfig

MPO Version: 1.3.0

Configuration details for permission basics, including permission groups.

interface PermissionBasicsConfig = {
  permissionGroups : PermissionGroup[];
}

PermissionGroup

MPO Version: 1.3.0

Defines a group of permissions under a shared namespace. Each permission group has a unique groupName and a list of permissions that are referenced across the project using either 'groupName.permission' or standalone permission identifiers. These groups simplify permission management in large-scale projects.

interface PermissionGroup = {
  groupName : String;
  permissions : String[];
}

RBACSettings

MPO Version: 1.3.0

Configuration for Role-Based Access Control (RBAC) within the project. When enabled, RBAC allows permissions to be assigned to named roles, which are then associated with users. This setup supports both single-role and multi-role configurations, along with custom logical roles defined by dynamic lookup conditions.

interface RBACSettings = {
  rbacIsActive : Boolean;
  configuration : RBACSettingsConfig;
}

RBACSettingsConfig

MPO Version: 1.3.0

Configuration details for RBAC, including roles, role ID data type, custom role lookups, and multi-role support.

interface RBACSettingsConfig = {
  rolesObject : RoleItem[];
  customRoleLookups : DataMapItem[];
  usersHaveMultipleRoles : Boolean;
}

RoleItem

MPO Version: 1.3.0

Represents a role definition in the RBAC system. Each role includes a name for display and a value used in session data and permission checks.

interface RoleItem = {
  name : String;
  value : Any;
}

PermissionTypes

MPO Version: 1.3.0

Defines the active permission mechanisms in the project. Mindbricks supports multiple types of permission strategies including role-based (RBAC), user-specific overrides, user group-level permissions, object-level (OBAC), and tenant-specific rules. This configuration determines which of these models are enabled for the access control logic.

interface PermissionTypes = {
  roleBasedPermissionsIsActive : Boolean;
  userBasedPermissionsIsActive : Boolean;
  userGroupBasedPermissionsIsActive : Boolean;
  objectBasedPermissionsIsActive : Boolean;
  tenantBasedPermissionsIsActive : Boolean;
}

OBACPermission

MPO Version: 1.3.0

Configuration for Object-Based Access Control (OBAC), which restricts access to specific data objects based on object ownership or association. If your system requires permissions that vary per object instance (e.g., 'only the creator can edit this record'), OBAC should be enabled and the relevant data objects listed.

interface OBACPermission = {
  objectBasedPermissionsIsActive : Boolean;
  dataObjects : DataObjectName[];
}

DataObjectName

MPO Version: 1.3.0

Represents a reference to a data object within the project. The value can be either a simple object name or a qualified reference in the format 'serviceName:objectName'. When using the qualified format, the part before the ':' specifies the service name, and the part after specifies the object name within that service. If only a single name is provided (without ':'), the system first searches for the object in the current service, then searches across other services in the project. As a best practice, when referencing data objects from other services, always fully qualified 'serviceName:objectName' format should be used to avoid potential naming conflicts.

interface DataObjectName = {
}

AbacPermission

MPO Version: 1.3.0

Configuration for Attribute-Based Access Control (ABAC), allowing fine-grained permission control using attribute-level rules on data objects. ABAC evaluates access by applying custom filter conditions to each object. When a rule matches, the user session may be granted specific permissions or even dynamic roles for that object. These rules can supplement or override standard RBAC or OBAC logic.

interface AbacPermission = {
  attributeBasedPermissionsIsActive : Boolean;
  abacDefinitions : ABACDefinititon[];
}

ABACDefinititon

MPO Version: 1.3.0

Defines a single ABAC (Attribute-Based Access Control) rule for a given data object. Each rule applies a conditional filter to determine which records a user can access, and grants either dynamic permissions or a role for matching records.

interface ABACDefinititon = {
  name : String;
  dataObject : DataObjectName;
  whereClause : MScript;
  permissions : String[];
}

SocialLoginSettings

MPO Version: 1.3.0

Configuration for enabling social login support within the project. This object defines integration settings for third-party authentication providers, such as Google and Apple, allowing users to sign in or register using their existing accounts. Each provider must be configured with its credentials and registration behavior.

interface SocialLoginSettings = {
  google : GoogleLoginSetting;
  apple : AppleLoginSetting;
  gitlab : GitlabLoginSetting;
  github : GithubLoginSetting;
}

GoogleLoginSetting

MPO Version: 1.3.0

Configuration for Google OAuth login. This section defines whether Google login is enabled, the client ID and secret, and whether users can register using their Google accounts.

interface GoogleLoginSetting = {
  useGoogleLogin : Boolean;
  configuration : GoogleLoginConfig;
}

GoogleLoginConfig

MPO Version: 1.3.0

Configuration details for Google OAuth login, including client ID, secret, and registration behavior. This object is used when Google login is enabled.

interface GoogleLoginConfig = {
  clientId : String;
  clientSecret : String;
  useForRegister : Boolean;
}

AppleLoginSetting

MPO Version: 1.3.0

Configuration for Apple OAuth login. This section defines whether Apple login is enabled, the client ID, and whether users can register using their Apple accounts.

interface AppleLoginSetting = {
  useAppleLogin : Boolean;
  configuration : AppleLoginConfig;
}

AppleLoginConfig

MPO Version: 1.3.0

Configuration details for Apple OAuth login, including client ID and registration behavior. This object is used when Apple login is enabled.

interface AppleLoginConfig = {
  clientId : String;
  useForRegister : Boolean;
}

GitlabLoginSetting

MPO Version: 1.3.0

Configuration for GitLab OAuth login. This section defines whether GitLab login is enabled, the client ID and secret, and whether users can register using their GitLab accounts.

interface GitlabLoginSetting = {
  useGitlabLogin : Boolean;
  configuration : GitlabLoginConfig;
}

GitlabLoginConfig

MPO Version: 1.3.0

Configuration details for GitLab OAuth login, including client ID, secret, and registration behavior. This object is used when GitLab login is enabled.

interface GitlabLoginConfig = {
  clientId : String;
  clientSecret : String;
  useForRegister : Boolean;
}

GithubLoginSetting

MPO Version: 1.3.0

Configuration for GitHub OAuth login. This section defines whether GitHub login is enabled, the client ID and secret, and whether users can register using their GitHub accounts.

interface GithubLoginSetting = {
  useGithubLogin : Boolean;
  configuration : GithubLoginConfig;
}

GithubLoginConfig

MPO Version: 1.3.0

Configuration details for GitHub OAuth login, including client ID, secret, and registration behavior. This object is used when GitHub login is enabled.

interface GithubLoginConfig = {
  clientId : String;
  clientSecret : String;
  useForRegister : Boolean;
}

DataProperty

MPO Version: 1.3.0

The definition of a data property within a data object. A data property is not just a storage field—it encapsulates the logic, behavior, and metadata associated with a specific piece of data. Through its settings, a data property can define relationships, context-aware values, session-based defaults, computed formulas, access filters, enums, and more. It serves as a powerful unit of business logic tightly integrated with the data model.

interface DataProperty = {
  basicSettings : PropertyBasicSettings;
  indexSettings : PropertyIndexSettings;
  enumSettings : PropertyEnumSettings;
  relationSettings : PropertyRelation;
  sessionSettings : PropertySessionSettings;
  staticJoin : PropertyStaticJoin;
  formulaSettings : PropertyFormulaSettings;
  contextSettings : PropertyContextSettings;
  filterSettings : PropertyFilterSettings;
}

PropertyBasicSettings

MPO Version: 1.3.0

Defines the core structure and behavior of a data property. Beyond basic typing, this section governs how the property participates in data integrity, mutability, API exposure, and logic-driven behaviors such as hashing or auto-increment. Use this section to establish the foundational logic and identity of the property within your data object.

interface PropertyBasicSettings = {
  name : String;
  type : DataTypes;
  isArray : Boolean;
  description : Text;
  isRequired : Boolean;
  allowUpdate : Boolean;
  requiredInUpdate : Boolean;
  allowAutoUpdate : Boolean;
  autoIncrement : Boolean;
  hashed : Boolean;
  defaultValues : PropertyDefaults;
}

DataTypes

These are the standardized data types used in microservice data models and BFF data views in Mindbricks.

DataTypesNames = [
  "ID",
  "String",
  "Text",
  "Integer",
  "Boolean",
  "Double",
  "Float",
  "Short",
  "Object",
  "Date",
  "Enum",
  "GeoPoint",
  "GeoRoute",
  "GeoArea",
];

const DataTypes = {
  ID: 0,
  String: 1,
  Text: 2,
  Integer: 3,
  Boolean: 4,
  Double: 5,
  Float: 6,
  Short: 7,
  Object: 8,
  Date: 9,
  Enum: 10,
  GeoPoint: 11,
  GeoRoute: 12,
  GeoArea: 13,
};

PropertyDefaults

MPO Version: 1.3.0

Defines fallback values for create and update operations when the property is not explicitly provided. These settings ensure consistency and reduce frontend responsibility in form submission. Values must match the JSON representation of the property's type (DataTypes) and isArray setting. Examples: String→"text", Integer→123, Boolean→true, Date→"2024-01-01T00:00:00Z", Enum→"enumValueAsStr", Object→{}, or wrapped in arrays like ["text1","text2"] when isArray=true. Note that the Enum type is represented by string value here instead of the Integer index.

interface PropertyDefaults = {
  default : AnyComplex;
  defaultInUpdate : AnyComplex;
  alwaysCreateWithDefaultValue : Boolean;
}

PropertyIndexSettings

MPO Version: 1.3.0

Index configuration for the data property across supported storage and caching layers. This includes Elasticsearch indexing for query performance, relational database indexing for faster selection, and Redis-based optimizations for efficient cache invalidation and retrieval. Use these settings to control how the property contributes to performance, queryability, and caching logic.

interface PropertyIndexSettings = {
  indexedInElastic : Boolean;
  fulltextSearch : Boolean;
  indexedInDb : Boolean;
  unique : Boolean;
  clusterInRedis : Boolean;
  cacheSelect : Boolean;
  isSecondaryKey : Boolean;
}

PropertyEnumSettings

MPO Version: 1.3.0

Enum configuration for the data property, applicable when the property type is set to Enum. While enum values are stored as integers in the database, defining the enum options here allows Mindbricks to enrich API responses with human-readable labels, easing interpretation and UI integration. If not defined, only the numeric value will be returned.

interface PropertyEnumSettings = {
  hasEnumOptions : Boolean;
  configuration : PropertyEnumSettingsConfig;
}

PropertyEnumSettingsConfig

MPO Version: 1.3.0

Configuration settings for enum options in a data property. This object defines the symbolic names that the enum type property can have. These labels are used in generated documentation and API responses.

interface PropertyEnumSettingsConfig = {
  enumOptions : String[];
}

PropertyRelation

MPO Version: 1.3.0

Defines the relationship configuration for the data property. This is used when the property acts as a foreign key referencing another data object. It allows setting up parent-child relationships, cascade behaviors, and enriches both code generation and documentation with relational semantics.

interface PropertyRelation = {
  hasRelation : Boolean;
  configuration : PropertyRelationConfig;
}

PropertyRelationConfig

MPO Version: 1.3.0

Configuration object for property relations. Defines the details of the foreign key relationship, including the relation name, target object, target key, parent/child semantics, delete behavior, and whether the relation is required. Used only if hasRelation is true.

interface PropertyRelationConfig = {
  relationName : String;
  relationTargetObject : DataObjectName;
  relationTargetKey : PropRefer;
  relationTargetIsParent : Boolean;
  onDeleteAction : RelationOnDeleteAction;
  relationIsRequired : Boolean;
}

RelationOnDeleteAction

Defines the available strategies for handling related records when a referenced (parent) object is deleted.

RelationOnDeleteActionNames = ["doDelete", "setNull"];

const RelationOnDeleteAction = {
  doDelete: 0,
  setNull: 1,
};

PropRefer

MPO Version: 1.3.0

Represents a reference to a property of a data object, optionally renaming it in the current context. It is a string data, however can store string pairs joined with ':'.The first part is the name ofthe property and the second part after ':' mark is how it will be renamed in the context. If no second partis provided, the property is named in the context with its original name. Renaming is useful for mapping remote object properties to local aliases or transforming naming for aggregation.

interface PropRefer = {
}

PropertySessionSettings

MPO Version: 1.3.0

Defines how this property is populated from the session context. Session-driven properties are commonly used to associate records with the current user or tenant automatically during create/update operations.

interface PropertySessionSettings = {
  isSessionData : Boolean;
  configuration : PropertySessionSettingsConfig;
}

PropertySessionSettingsConfig

MPO Version: 1.3.0

Configuration object for session mapping. Defines the mapping between session properties and data object fields. This allows automatic population of data object properties from session data during create/update operations.

interface PropertySessionSettingsConfig = {
  sessionParam : String;
  isOwnerField : Boolean;
}

PropertyStaticJoin

MPO Version: 1.3.0

Static join settings define how this property's value is derived from another data object at the time of creation or update. This approach is useful when a field in the current object depends on a static value from a related object, and that value is not expected to change frequently. Unlike dynamic joins, static joins store the fetched value directly to allow for faster queries and avoid repeated lookups. A common use case is transferring tenant or client identifiers from a parent object into a child record. For example, when creating an email job for a specific user, the system can use the userId to join the User object, fetch its clientId, and statically assign it to the EmailJob object. This makes it easy to query email jobs by clientId without needing to join back to the User table at runtime. Note that, all static joins are executed before the property formula executions and the fetched data and read property (field) is written to the context like this.product and this.amount, so you can use these context data with in the calculated properties for either the same joint property or for another property.

interface PropertyStaticJoin = {
  isStaticJoin : Boolean;
  configuration : PropertyStaticJoinConfig;
}

PropertyStaticJoinConfig

MPO Version: 1.3.0

Configuration object for static joins. This object contains the settings that define how the static join is established, including the source object, the field to be joined, and the keys used for matching records. It is used in conjunction with the isStaticJoin property to enable static joins in data objects.

interface PropertyStaticJoinConfig = {
  jointSource : DataObjectName;
  jointRead : PropRefer;
  jointSourceKey : PropRefer;
  jointForeignKey : PropRefer;
}

PropertyFormulaSettings

MPO Version: 1.3.0

Specifies formula-based logic for computing the value of a data property. Use this when the property should not be directly provided by the user but instead derived through predefined calculations during create or update operations. Note that formula caluclations are made at the final point of the data clause building, so you can acess other property values that are populated from other sources. The formulas are calculated in create and update api's, so these API's will automatically manage the calculated population of the related properties. If you need more complex calculations in API level, you can use dataClause settings of the API combined with Api actions.

interface PropertyFormulaSettings = {
  isCalculated : Boolean;
  configuration : PropertyFormulaSettingsConfig;
}

PropertyFormulaSettingsConfig

MPO Version: 1.3.0

Configuration object for formula-based calculation. Defines the primary formula and optional update formula for computed properties. This allows dynamic calculation of values during create or update operations.

interface PropertyFormulaSettingsConfig = {
  formula : MScript;
  updateFormula : MScript;
  calculateWhenInputHas : PropRefer[];
  calculateAfterInstance : Boolean;
}

PropertyContextSettings

MPO Version: 1.3.0

Defines how this property is automatically populated from the request-time execution context. This is useful when the property value is fetched or computed externally before being written to the database—such as through API fetches, middleware injections, or upstream aggregations.

interface PropertyContextSettings = {
  isContextData : Boolean;
  configuration : PropertyContextSettingsConfig;
}

PropertyContextSettingsConfig

MPO Version: 1.3.0

Configuration object for context mapping. Defines the mapping between context properties and data object fields. This allows automatic population of data object properties from context data during create/update operations.

interface PropertyContextSettingsConfig = {
  contextParam : String;
}

PropertyFilterSettings

MPO Version: 1.3.0

Specifies if a data property should be exposed as a query parameter for filtering in auto-generated list endpoints. This allows users to filter records by this field when retrieving data via GET routes. The presence of this configuration determines how the backend interprets and applies client-side query filters.

interface PropertyFilterSettings = {
  isFilterParameter : Boolean;
  configuration : PropertyFilterSettingsConfig;
}

PropertyFilterSettingsConfig

MPO Version: 1.3.0

Configuration object for filter settings. Defines the custom name of the filter parameter in the query string. This is useful when the external API should expose a different term than the internal field name.

interface PropertyFilterSettingsConfig = {
  filterName : String;
}

BFFService

MPO Version: 1.3.0

The BFF (Backend-for-Frontend) service is strongly recommended in microservice-based projects to simplify and optimize data access for frontend clients. As data is distributed across multiple services, the BFF service acts as a unified gateway that aggregates and delivers the necessary information in a single response. Mindbricks supports a hybrid CQRS architecture using DataViews, which represent structured aggregations of service data. These can be configured as either Static or Dynamic DataViews. Static DataViews are persisted in Elasticsearch and are ideal for performance-critical or cross-service filtered queries. Dynamic DataViews, on the other hand, fetch and assemble data on-the-fly during each request, making them suitable for user-specific or context-dependent views without storing the output. If no DataViews are defined, the BFF service will not be generated as part of the project.

interface BFFService = {
  dataViews : DataView[];
}

DataView

MPO Version: 1.3.0

A DataView defines an aggregated projection of data for the BFF service in Mindbricks. It serves as a unified structure that collects and combines information from multiple microservices. DataViews can be configured as either stored or dynamic. Stored DataViews persist their results in Elasticsearch and are optimal for queries requiring filtering, sorting, or cross-service joins. Dynamic DataViews are assembled at runtime during the request cycle and are suitable for lightweight, user-specific, or real-time scenarios. Both types aim to simplify frontend development by consolidating distributed data into a single, queryable view.

interface DataView = {
  viewBasics : ViewBasics;
  aggregates : ViewAggregate[];
  lookups : ViewLookup[];
  stats : ViewStat[];
}

ViewBasics

MPO Version: 1.3.0

Configuration for a DataView's identity and structure. It specifies whether the view is stored (in Elasticsearch) or dynamic (evaluated at runtime), the name of the view, the main source object it is built upon, and the list of core properties to retrieve from the main object.

interface ViewBasics = {
  name : String;
  isStored : Boolean;
  mainObject : DataObjectName;
  properties : PropRefer[];
}

ViewAggregate

MPO Version: 1.3.0

Defines an aggregate (join) within a DataView that links related objects to the main object, similar to SQL-style joins. Aggregates are resolved at the Elasticsearch layer using replicated microservice data. Each aggregate pulls in one or more records from a child object based on matching keys and optional conditions, then embeds them under the specified property name in the final view output.

interface ViewAggregate = {
  name : String;
  childObject : DataObjectName;
  parentKey : PropRefer;
  childKey : PropRefer;
  oneToMany : Boolean;
  condition : MScript;
  properties : PropRefer[];
  checkIn : MScript;
}

ViewLookup

MPO Version: 1.3.0

Defines a lookup operation in a DataView, typically used to enrich an object with a human-readable label or translated text from a dictionary index. Lookups are similar to aggregates but are optimized for fetching a single value, such as a label, for UI rendering. They are especially useful for localization (e.g., converting 'userType: 0' to 'Administrator') or enriching records with descriptive names from static dictionaries like country, city, or status lists. Multi-language lookups automatically resolve language-specific values based on the user's locale if the view is dynamic; if stored, all language variants are stored with suffixes.

interface ViewLookup = {
  name : String;
  lookupDict : String;
  multiLang : Boolean;
  lookupKey : String;
  lookupValue : String;
}

ViewStat

MPO Version: 1.3.0

Defines a statistical aggregation for a DataView. Unlike ViewAggregates that collect related records, ViewStats compute mathematical summaries such as sum, count, average, min, and max over grouped data. These groupings, or 'buckets', are constructed based on parent-child relationships between objects. This is conceptually similar to Elasticsearch's bucket-based aggregations. Each ViewStat joins the main object with a target object (child) using a foreign key relationship and computes one or more aggregates using the defined conditions. It's ideal for summarizing numerical data across associations, such as counting user orders or summing revenue per company.

interface ViewStat = {
  name : String;
  childObject : DataObjectName;
  parentKey : PropRefer;
  childKey : PropRefer;
  select : MScript;
  aggList : AggregateItem[];
}

AggregateItem

MPO Version: 1.3.0

Defines a single mathematical operation to apply to a group of records within a ViewStat. Supports standard operations like sum, average, min, max, and count. Each AggregateItem targets a specific field in the child object and may apply additional filters. It is particularly useful when multiple grouped metrics are required from the same set of joined records, such as 'count of failed orders' vs. 'sum of successful order values'.

interface AggregateItem = {
  name : String;
  aggType : String;
  aggField : PropRefer;
  dataType : DataTypes;
  filterValue : MScript;
}

NotificationService

MPO Version: 1.3.0

Defines the global notification configuration for the project. This includes providers for different notification channels and the list of event-driven notification behaviors triggered by Kafka messages.

interface NotificationService = {
  serviceSettings : NotificationServiceSettings;
  eventNotifications : EventNotification[];
}

NotificationServiceSettings

MPO Version: 1.3.0

Defines the basic notification configuration for the project. This includes the notification options providers for different notification channels such as SMS, email, and push notifications.

interface NotificationServiceSettings = {
  serviceOptions : NotificationServiceOptions;
  smtpSettings : SmtpSettings;
  amazonSNSSettings : AmazonSNSSettings;
  firebaseSettings : FirebaseSettings;
  sendGridSettings : SendGridSettings;
  twilioSettings : TwilioSettings;
  vonageSettings : VonageSettings;
  netGsmSettings : NetGSMSettings;
  oneSignalSettings : OneSignalSettings;
}

NotificationServiceOptions

MPO Version: 1.3.0

Defines the global notification configuration for the project. This includes providers for different notification channels and the list of event-driven notification behaviors triggered by Kafka messages.

interface NotificationServiceOptions = {
  storedNotice : Boolean;
  smsProvider : SmsProvider;
  emailProvider : EmailProvider;
  pushProvider : PushProvider;
}

SmsProvider

Defines valid SMS providers for project-wide notifications.

SmsProviderNames = ["amazonsns", "fake", "netgsm", "twilio", "vonage"];

const SmsProvider = {
  amazonsns: 0,
  fake: 1,
  netgsm: 2,
  twilio: 3,
  vonage: 4,
};

EmailProvider

Defines valid email providers for project-wide notifications.

EmailProviderNames = ["amazonsns", "fake", "sendgrid", "smtp"];

const EmailProvider = {
  amazonsns: 0,
  fake: 1,
  sendgrid: 2,
  smtp: 3,
};

PushProvider

Defines valid push notification providers for project-wide delivery.

PushProviderNames = ["amazonsns", "fake", "firebase", "onesignal"];

const PushProvider = {
  amazonsns: 0,
  fake: 1,
  firebase: 2,
  onesignal: 3,
};

SmtpSettings

MPO Version: 1.3.0

Defines configuration for using a custom SMTP server to send emails. Mindbricks uses a managed cloud provider by default, but you may configure your own server here.

interface SmtpSettings = {
  useCustomSmptServer : Boolean;
  configuration : SmtpSettingsConfig;
}

SmtpSettingsConfig

MPO Version: 1.3.0

Defines the configuration for a custom SMTP server. This object is used when useCustomSmptServer is set to true. It includes the host, port, authentication, and security details.

interface SmtpSettingsConfig = {
  emailFrom : String;
  emailHost : String;
  emailPort : Integer;
  emailUser : String;
  emailPass : String;
  isSecure : Boolean;
}

AmazonSNSSettings

MPO Version: 1.3.0

Defines configuration for integrating Amazon SNS for messaging and notifications. Mindbricks does not provide a managed SNS setup, so you must supply your own credentials if you choose to use this service.

interface AmazonSNSSettings = {
  useAmazonSNS : Boolean;
  configuration : AmazonSNSSettingsConfig;
}

AmazonSNSSettingsConfig

MPO Version: 1.3.0

Defines the configuration for Amazon SNS. This object is used when useAmazonSNS is set to true. It includes the secret key, access key, and region.

interface AmazonSNSSettingsConfig = {
  secretKey : String;
  accessKey : String;
  region : String;
}

FirebaseSettings

MPO Version: 1.3.0

Defines configuration for using Firebase services. Mindbricks does not include Firebase by default, so this setup is required only if Firebase will be used for messaging or real-time features.

interface FirebaseSettings = {
  useFirebase : Boolean;
  configuration : FirebaseSettingsConfig;
}

FirebaseSettingsConfig

MPO Version: 1.3.0

Defines the configuration for Firebase. This object is used when useFirebase is set to true. It includes the API key for Firebase services.

interface FirebaseSettingsConfig = {
  firebaseKey : String;
}

SendGridSettings

MPO Version: 1.3.0

Defines configuration for integrating SendGrid to send transactional or notification emails. You must register a SendGrid account and provide your API key.

interface SendGridSettings = {
  useSendGrid : Boolean;
  configuration : SendGridSettingsConfig;
}

SendGridSettingsConfig

MPO Version: 1.3.0

Defines the configuration for SendGrid. This object is used when useSendGrid is set to true. It includes the API key and sender email address.

interface SendGridSettingsConfig = {
  sendGridApiKey : String;
  sendGridFromEmail : String;
}

TwilioSettings

MPO Version: 1.3.0

Defines configuration for using Twilio to send SMS or perform voice operations. Mindbricks does not provide a managed Twilio account, so integration must be configured here.

interface TwilioSettings = {
  useTwilio : Boolean;
  configuration : TwilioSettingsConfig;
}

TwilioSettingsConfig

MPO Version: 1.3.0

Defines the configuration for Twilio. This object is used when useTwilio is set to true. It includes the Account SID, authentication token, and sender identity.

interface TwilioSettingsConfig = {
  twilioAccountSid : String;
  twilioAuthToken : String;
  twilioSender : String;
}

VonageSettings

MPO Version: 1.3.0

Defines configuration for integrating Vonage as an SMS provider. Provide credentials for your Vonage account if this service is used.

interface VonageSettings = {
  useVonage : Boolean;
  configuration : VonageSettingsConfig;
}

VonageSettingsConfig

MPO Version: 1.3.0

Defines the configuration for Vonage. This object is used when useVonage is set to true. It includes the token and sender name/number.

interface VonageSettingsConfig = {
  vonageToken : String;
  vonageSender : String;
}

NetGSMSettings

MPO Version: 1.3.0

Defines configuration for using the Turkish SMS provider NetGSM. You must supply your own credentials to use this service in Mindbricks.

interface NetGSMSettings = {
  useNetGSM : Boolean;
  configuration : NetGSMSettingsConfig;
}

NetGSMSettingsConfig

MPO Version: 1.3.0

Defines the configuration for NetGSM. This object is used when useNetGSM is set to true. It includes the username, password, and sender ID.

interface NetGSMSettingsConfig = {
  netGsmUsername : String;
  netGsmPassword : String;
  netGsmSender : String;
}

OneSignalSettings

MPO Version: 1.3.0

Defines configuration for OneSignal push notifications. Mindbricks does not manage OneSignal accounts, so a valid app ID and API key must be provided.

interface OneSignalSettings = {
  useOneSignal : Boolean;
  configuration : OneSignalSettingsConfig;
}

OneSignalSettingsConfig

MPO Version: 1.3.0

Defines the configuration for OneSignal. This object is used when useOneSignal is set to true. It includes the app ID and REST API key.

interface OneSignalSettingsConfig = {
  oneSignalAppId : String;
  oneSignalApiKey : String;
}

EventNotification

MPO Version: 1.3.0

Defines a single event-triggered notification within the project. These notifications are triggered by messages on a Kafka topic and can be sent as email, SMS, push, or in-app messages depending on configuration.

interface EventNotification = {
  eventNotificationBasics : EventNotificationBasics;
  eventDataSettings : EventDataSettings;
  targets : NotificationTarget[];
  template : NotificationTemplate;
}

EventNotificationBasics

MPO Version: 1.3.0

Defines the basic properties of an event notification, including its name, description, storage behavior, and job type. This section is used to configure how the notification behaves and what type of message it sends.

interface EventNotificationBasics = {
  name : String;
  description : Text;
  isStored : Boolean;
  jobType : NotificationJobTypes;
  actionDeepLink : MScript;
  actionText : MScript;
  fromUser : MScript;
}

NotificationJobTypes

Specifies the medium through which the notification will be sent.

NotificationJobTypesNames = ["email", "sms", "push", "inApp"];

const NotificationJobTypes = {
  email: 0,
  sms: 1,
  push: 2,
  inApp: 3,
};

EventDataSettings

MPO Version: 1.3.0

Defines how the event notification extracts and processes data from incoming Kafka messages. This includes the data source, paths to relevant information, and any additional data to include in the notification.

interface EventDataSettings = {
  channel : String;
  condition : MScript;
  dataViewName : String;
  dataViewIdPathInPayload : String;
  includeData : DataMapItem[];
}

NotificationTarget

MPO Version: 1.3.0

Defines a recipient or list of recipients for an event notification. Targets are derived from the notification data and can be conditional.

interface NotificationTarget = {
  targetName : String;
  targetPathInData : String;
  isArray : Boolean;
  targetUserIdInArrayTargetItem : String;
  targetItemNameInArray : String;
  condition : MScript;
}

NotificationTemplate

MPO Version: 1.3.0

Defines a notification template used to render the content of event notifications. Templates are written in EJS and can include dynamic data from the notification payload.

interface NotificationTemplate = {
  name : String;
  description : Text;
  subjectTemplate : Text;
  bodyTemplate : Text;
  parser : String;
}

Service

MPO Version: 1.3.0

Defines the overall structure and configuration for a microservice within the project. Each service acts as an independent domain that encapsulates its own data model, business logic, and interface behaviors. While services primarily manage and expose domain-specific data, this module extends beyond basic CRUD operations by offering customizable patterns, libraries, authentication, and specialized route handling. Use this module to tailor the internal and external behaviors of your service—whether it's securing endpoints, defining edge routes, managing complex data objects, or integrating advanced logic. The service configuration ensures the resulting microservice is robust, secure, and aligned with the specific application requirements.

interface Service = {
  serviceSettings : ServiceSettings;
  dataObjects : DataObject[];
  businessLogic : BusinessApi[];
  library : ServiceLibrary;
  edgeControllers : EdgeController[];
}

ServiceSettings

MPO Version: 1.3.0

Defines the foundational settings of the service module, including basic metadata and authentication configurations. These settings must be established before designing the service's data model. They determine the service's identity, behavior within the project, and how it handles authentication. This configuration acts as the entry point for service-level behavior, ensuring consistency and security from the outset of development.

interface ServiceSettings = {
  serviceBasics : ServiceBasics;
  serviceOptions : ServiceOptions;
}

ServiceBasics

MPO Version: 1.3.0

Provides core identifiers and metadata for the service. Includes the service's internal ID, a unique name (used in code, routing, and service naming), a descriptive text for documentation, and any custom variables required for runtime configuration.

interface ServiceBasics = {
  id : String;
  name : String;
  description : Text;
  frontendDocument : Text;
  customVariables : DataMapSimpleItem[];
  nodejsPackages : NodeJsPackageItem[];
}

NodeJsPackageItem

MPO Version: 1.3.0

An object to define a nodejs npm package requirement to be added to the nodejs package json of the service

interface NodeJsPackageItem = {
  packageName : String;
  version : String;
  defaultImportConst : String;
}

ServiceOptions

MPO Version: 1.3.0

Defines a configuration class for the basic options of the service for authentication, http and data model

interface ServiceOptions = {
  serviceRequiresLogin : Boolean;
  serviceAllowsUserToLogin : Boolean;
  httpPort : Integer;
  routerSuffix : String;
  dataModelName : String;
  dbType : DbTypes;
  useSoftDelete : Boolean;
}

DbTypes

Enumeration of supported database types for service-level data models.

DbTypesNames = ["postgresql", "mongodb"];

const DbTypes = {
  postgresql: 0,
  mongodb: 1,
};