Building Your API in Mindbricks

Pattern shape — explicit-mode is the default for all new projects (Q2 2026 onwards). Every BusinessApi declares its full request shape via requestParameters and its full dataClause map via dataClauseItems. The framework auto-injects values from sessionSettings and staticJoin blocks on data properties; everything else is the designer's explicit declaration. The quick reference below covers the 80% case.

Explicit-mode quick reference (new projects)

For each create / update API, walk the data object's properties and decide per-property:

URL placeholders in restSettings.routePath (e.g. :teamId) auto-promote into requestParameters with httpLocation: 'urlpath' if not declared explicitly.

requestParameters[] shape:

{
  "name": "title",
  "type": "String",
  "isArray": false,
  "isRequired": true,
  "httpLocation": "body",
  "defaultValue": null,
  "transform": null,
  "description": "..."
}

dataClauseItems[] shape — name + value MScript:

[
  { "name": "title",  "value": "this.title" },
  { "name": "status", "value": "'pending'" },
  { "name": "score",  "value": "this.score || 0" }
]

Read / list / fetch APIs declare requestParameters (for filters, query strings, path placeholders) and whereClause. They have no dataClauseItems (no write payload).

basicSettings.defaultValue on a data property is a DB-level scalar default — load-bearing for NOT NULL columns where you want the database to fill the default for inserts that don't carry the column. Computed defaults (now(), LIB.<fn>(...)) belong in per-API dataClauseItems MScript, not on the property.

Anti-patterns (explicit-mode)

• Declaring a requestParameter for a property with sessionSettings or staticJoin. The framework's auto-inject is silently suppressed in favor of the caller's value. Auditor flags this as auto-injected-property-also-as-request-param (warning).
• Declaring a dataClauseItem for an auto-injected property. Same — the framework handles those at write time.
• Forgetting a dataClauseItem for a non-auto-inject property. The DB column ends up unset (NULL or NOT-NULL violation). Auditor catches this as missing-dataClauseItem-for-property.
• Hard literal in a dataClauseItem when the API contract should expose the field. value: "this.X || '<default>'" is the pattern for caller-with- fallback; hard literals silently override caller input.

Overview

Mindbricks operates around two fundamental architectural concepts — Data Objects and Business APIs. At first glance, it might seem that Data Objects are only about data structure while Business APIs are only about endpoints. While that’s partly true, it’s far from the whole picture.

A Data Object in Mindbricks begins as a simple schema definition, but through its dbObject and dbProperty configurations, it evolves into a rich, logic-driven construct. Each property or object-level attribute can influence how Mindbricks automatically builds business logic around that data. For example:

• When a property is marked as a session-populated property, its management within create or update API flows is automatically handled by Mindbricks.

• When a property is defined as a static join, the create and update APIs will automatically populate it using its defined relationship to another Data Object.

Beyond individual properties, object-level settings can also embed logic. For example, marking a Data Object with membership logic or payment logic enriches all APIs that interact with it.

Route Generation and Compatibility Note

Mindbricks generates REST paths from your API naming and template conventions.
Older projects may expose /v1/... style routes while newer generations can use different normalized paths.

For production/frontend contracts:

• Always verify concrete paths from generated API documentation/assets for the target project.
• Avoid hardcoding route assumptions across shared frontend libraries.
• Prefer central route constants generated from your service docs when possible.

From Data Objects to Business APIs

A Business API in Mindbricks is not merely an endpoint definition — it’s an architectural workflow design triggered by an endpoint. This workflow consists of predefined milestones that represent the lifecycle of an operation (e.g., validation, data fetch, authorization, transformation, persistence). While many workflows are automatically generated for standard CRUD operations, they can be extended, modified, or completely redesigned through configuration and pattern composition.

Each Business API has its own behavior shaped by:

• Data object enrichments (e.g., property annotations, ownership logic)

• API-level configurations (e.g., where clauses, select clauses, custom parameters)

• Workflow customization through Business API Actions

Even without any additional configuration, a Data Object definition is enough to generate a complete set of APIs — get, getList, create, update, and delete — ready for use.

However, Mindbricks extends far beyond simple data management. It is a logic machine, offering a wide array of architectural and behavioral control mechanisms for building complex business processes.

Workflow Design and Business Logic Customization

Mindbricks provides fine-grained control over API behavior through its workflow design layer. Each Business API has a structured execution pipeline consisting of milestones such as:

• afterStartBusinessApi — where you can attach an early PermissionCheckAction or ReadJwtTokenAction to validate access before processing begins.

• afterBuildWhereClause — suitable for adding MembershipCheckAction or ObjectPermissionCheckAction to ensure data-level security.

• afterFetchInstance — where you can enrich context using a FetchParentAction or CollateListsAction.

• afterMainUpdateOperation — ideal for adding a PublishEventAction or InterserviceCallAction after the main transaction.

• afterBuildOutput — commonly used to shape the response through AddToResponseAction or RemoveFromResponseAction.

These milestones act as controlled extension points, letting you weave additional logic into the lifecycle without altering the underlying CRUD structure.

Each Business API contains an actions store, where logic operations are defined and then attached to milestones. For example, you can insert:

• Validation or permission logic using ValidationAction, PermissionCheckAction, or MembershipCheckAction

• Data fetching and enrichment via FetchObjectAction, FetchStatsAction, or ReadFromRedisAction

• Custom transformations using FunctionCallAction or AddToContextAction

• Inter-service and integration logic with InterserviceCallAction or IntegrationAction

• Event and communication steps through PublishEventAction, SendMailAction, or SendPushNotificationAction

• AI or automation utilities such as AiCallAction or DataToFileAction

Together, these patterns form a modular, declarative logic framework where each milestone and action has a clear purpose and position within the flow — allowing APIs in Mindbricks to express highly customized business behavior while staying fully pattern-aligned.

Extending Beyond Patterns

While Mindbricks offers hundreds of predefined BusinessApiActions for declarative logic composition, it also empowers developers to go beyond patterns. You can write custom javascript functions, inline logic blocks, or even full JavaScript extensions to handle edge cases and unique business scenarios that patterns cannot yet express. These custom code fragments integrate directly into the same workflow system, coexisting with pattern-defined actions and following the same lifecycle semantics.

Bringing It All Together

In this document, we will learn how to build rich, pattern-based APIs that can express virtually unlimited types of business logic. We begin by understanding the BusinessApi pattern — the central element of Mindbricks’ logic architecture.

BusinessApi Pattern Definition

Even though each Business API is associated with a main Data Object, Business APIs are defined at the service level, inside the businessLogic property of the Service pattern.

"Service": {
  // ...
  "businessLogic": ["BusinessApi"],
  // ...
}

Each entry in this array is a BusinessApi definition. Below is the structure of the BusinessApi pattern, which encapsulates all configurable aspects of an API — from authentication to workflow design.

BusinessApi Pattern

"BusinessApi": {
  "__apiOptions.doc": "Defines the name, type, dataObject, and description of the business API, as well as its basic options.",
  "__authOptions.doc": "Defines core authentication and authorization settings for a Business API. These settings cover session validation, role and ownership checks, and access scope (e.g., tenant vs. SaaS-level). While these options are sufficient for most use cases, more fine-grained access control—such as conditional permissions or contextual ownership—should be implemented using explicit access control actions (e.g., `PermissionCheckAction`, `MembershipCheckAction`, `ObjectPermissionCheckAction`).",
  "__requestParameters.doc": "An array of `BusinessApiParameter` entries declaring every input the API accepts (name, type, isRequired, httpLocation, optional defaultValue / transform). Each entry is written to the context as `this.<name>` before workflow execution.",
  "__dataClauseItems.doc": "An array of `DataMapItem` entries defining how each `create` / `update` API writes the dataClause map. Each entry has a `name` (the property on the data object) and a `value` (an MScript expression — typically `this.<paramName>` for caller-supplied values or a literal / MScript for system-managed values). Properties bound via `sessionSettings` or `staticJoin` are auto-injected by the framework and must not appear here.",
  "__redisParameters.doc": "An array of parameters fetched from Redis based on dynamically computed keys. Defined using `RedisApiParameter` and written to the context as `this.<name>`, just like request parameters.",
  "__restSettings.doc": "Defines HTTP REST controller settings such as method and route path. Automatically generated using naming conventions but can be customized for fine-grained REST control.",
  "__grpcSettings.doc": "Enables gRPC access for this Business API and configures request/response schemas. Disabled by default unless explicitly configured.",
  "__kafkaSettings.doc": "Enables this API to be triggered by Kafka events. The controller listens for messages published to configured Kafka topics, enabling event-driven orchestration across services.",
  "__socketSettings.doc": "Enables invocation of this API over WebSocket channels, allowing real-time bidirectional communication.",
  "__cronSettings.doc": "Schedules this API for automatic execution at specified intervals using cron expressions. Commonly used for background jobs or periodic tasks.",
  "__selectClause.doc": "Specifies which fields to select from the main data object during `get` or `list` operations. Leave blank to select all.",
  "__whereClause.doc": "Defines criteria to locate target record(s) for `get`, `list`, `update`, or `delete` operations. Expressed as a query object. All API types except `list` are expected to target a single record. For `update` and `delete`, the actual database mutation uses the fetched instance's ID to guarantee single-record safety.",
  "__deleteOptions.doc": "Settings specific to `delete` type APIs, such as soft-delete or cascade behaviors.",
  "__getOptions.doc": "Settings for `get` APIs, including enrichment, fallback, or caching behavior.",
  "__listOptions.doc": "Defines list-specific options such as filtering, default sorting, and result customization.",
  "__paginationOptions.doc": "Configures pagination for `list` APIs, including page size, offset, cursor mode, and total count.",
  "__actions.doc": "Represents logic actions that can be referenced in the API's workflow. These include fetches, validations, permissions, transformations, and output shaping.",
  "__workflow.doc": "Defines the logical flow of the Business API — a sequence of action names grouped by lifecycle stages. Can be visualized in the architecture UI or generated programmatically.",

  "apiOptions": "ApiOptions",
  "authOptions": "ApiAuthOptions",

  "requestParameters": ["BusinessApiParameter"],
  "dataClauseItems": ["DataMapItem"],
  "redisParameters": ["RedisApiParameter"],

  "restSettings": "ApiRestSettings",
  "grpcSettings": "ApiGrpcSettings",
  "kafkaSettings": "ApiKafkaSettings",
  "socketSettings": "ApiSocketSettings",
  "cronSettings": "ApiCronSettings",

  "selectClause": "SelectClauseSettings",
  "whereClause": "WhereClauseSettings",
  "deleteOptions": "DeleteOptions",
  "getOptions": "GetOptions",
  "listOptions": "ListOptions",
  "paginationOptions": "PaginationOptions",
  "actions": "BusinessApiActionStore",
  "workflow": "BusinessWorkflow"
}

API-Type Specific Settings

The BusinessApi pattern serves as a universal container for all API types — get, list, create, update, and delete. While most of its settings are shared across all API types, certain configuration sections apply only to specific kinds of Business APIs, depending on their functional purpose.

The following mappings clarify which settings are type-specific:

• selectClause — applies only to get and list APIs.

• dataClauseItems — used in create and update APIs. For array-field updates inside dataClauseItems values, see Array Mutation Syntax Guide.

• whereClause — relevant for get, list, update, and delete (not used in create).

• deleteOptions — applies only to delete APIs.

• listOptions — applies only to list APIs.

• paginationOptions — applies only to list APIs.

All other settings — including authOptions, restSettings, actions, and workflow — are common across all Business APIs, providing a unified architecture that keeps behavior consistent regardless of operation type.

Understanding Basic Options of a Business API

A Business API in Mindbricks is defined by a small but crucial set of foundational options that determine its identity, behavior, and target data model. These are defined under the ApiOptions pattern and include attributes like name, description, crudType, and dataObjectName, each of which influences both code generation and runtime behavior.

"ApiOptions": {
  "__dataObjectName.doc": "Specifies the primary data object that this Business API interacts with. This object is the core target of the API's operation, such as reading, updating, or deleting records. Required even when dataViewName is set — the DataView's mainObject must match this dataObject.",

  "__dataViewName.doc": "Optional. Specifies the name of a DataView defined in the BFF service whose mainObject matches this API's dataObject. When set, all read/fetch operations (get, list, and fetchInstance for update/delete) use ElasticIndexer to query the DataView's Elasticsearch index. Write operations (create, update, delete) still execute against the database. For create, the result is enriched from the DataView after the DB insert.",

  "__crudType.doc": "Defines the primary operation type for this API. Possible values are `get`, `list`, `create`, `update`, and `delete`. This classification drives the behavior and flow of the API lifecycle.",

  "__name.doc": "A unique, human-readable name for the API, used for referencing in documentation and the UI. This is not a code-level identifier; instead, generated class and function names are derived from this value. Use camelCase formatting, avoid spaces or special characters, and ensure uniqueness within the same service. If you want the API to behave like a default RESTful endpoint, use a verb-noun combination like `createUser`, `getOrder`, or `deleteItem`, which will enforce expected parameters and URL patterns (e.g., `/users/:userId`).",

  "__apiDescription.doc": "A brief explanation of the API's business purpose or logic. Helps clarify its intent for developers and documentation readers.",

  "__raiseApiEvent.doc": "Indicates whether the Business API should emit an API-level event after successful execution. This is typically used for audit trails, analytics, or external integrations.",

  "__raiseDbLevelEvents.doc": "If true, database-level events will be emitted for each affected data object. This is useful for APIs that interact with multiple related objects and need fine-grained event tracking.",

  "__readFromEntityCache.doc": "If enabled, the API will attempt to read the target object from the Redis entity cache before querying the database. This can improve performance for frequently accessed records.",

  "__raiseDbLevelEvents.default": true,
  "__raiseApiEvent.default": true,
  "__readFromEntityCache.default": false,

  "dataObjectName": "DataObjectName",
  "dataViewName": "String",
  "crudType": "CrudTypes",
  "name": "String",
  "apiDescription": "Text",
  "raiseApiEvent": "Boolean",
  "raiseDbLevelEvents": "Boolean",
  "readFromEntityCache": "Boolean"
}

The dataObjectName and crudType Attributes

These two attributes define the core identity of a Business API.

• dataObjectName specifies which Data Object the API operates on — the central entity being read, created, or modified. Its type is DataObjectName, a special string reference used across Mindbricks. A Data Object name can be written directly (e.g., category) or with its service prefix (e.g., product:category). When the service name is omitted, Mindbricks first looks for the Data Object in the current service; if it’s not found there, it automatically checks the referenced service location in the project.

• crudType defines the type of operation, determining which workflow milestones and clauses are activated — such as create, update, delete, get, or list.

Together, these two options tell Mindbricks what the API does and where it applies, serving as the foundation for route generation, workflow selection, and automated logic scaffolding.

Using DataViews with Business APIs

Mindbricks supports an optional DataView overlay on any Business API. A DataView is a read-optimized, denormalized view defined in the BFF Service and stored in Elasticsearch. By setting the dataViewName attribute in ApiOptions, a Business API can leverage the DataView's enriched data for all read and fetch operations while continuing to use the database for write operations.

How It Works

The dataObjectName is always required — it identifies the local Data Object that the API targets. The dataViewName is optional and must reference a DataView whose mainObject matches the selected dataObjectName. Mindbricks validates this consistency at build time; if the DataView's main object does not match, the DataView setting is ignored with a warning.

When a Business API has a valid dataViewName, its behavior changes depending on the CRUD type:

• Get and List — The database script is replaced entirely. Data is fetched from the DataView's Elasticsearch index using ElasticIndexer. Where clause filters, pagination, and sorting are converted to Elasticsearch queries automatically.

• Update and Delete — The fetchInstance step (which retrieves the current record before modification) reads from Elasticsearch, giving the API access to the full DataView data including joined and computed fields. This allows validation and ownership checks against the enriched view. The actual update or delete operation still executes against the database. The where clause used for fetchInstance is converted to an Elastic query while the where clause for the DB operation remains in the native database format.

• Create — The record is created in the database as usual. After a successful insert, the API automatically attempts to fetch the newly created record from the DataView's Elasticsearch index to return the enriched result (with all joined and extended data) in the response.

Security and Where Clause Handling

All security filters — tenant isolation, ownership checks, conditional clauses — are fully respected in DataView mode. The where clause builder produces both a database-compatible query (for write operations) and an Elastic-compatible query (for read operations from the DataView). This ensures that fetchInstance in update/delete flows enforces the same access control as standard database-backed APIs.

Configuration Example

{
  "apiOptions": {
    "dataObjectName": "product",
    "dataViewName": "ProductDetailView",
    "crudType": "list",
    "name": "listProductDetails"
  }
}

In this example, the listProductDetails API targets the product Data Object but reads from the ProductDetailView DataView in Elasticsearch. The DataView might include joined data such as category names, supplier details, or computed fields — all returned without additional fetch actions.

Requirements

• The dataObjectName must always be set and must be a local Data Object within the current service.
• The dataViewName must reference a DataView defined in the project's BFF Service.
• The DataView's mainObject must match the selected dataObjectName.
• The DataView's Elasticsearch index must be maintained and kept in sync (typically handled by the BFF service's indexing pipeline).

Understanding the name Attribute

The name of a Business API is far more than a label — it acts as a semantic anchor that drives automatic generation of REST routes, event names, and internal code identifiers. Mindbricks interprets this name intelligently to ensure both readability and consistency across documentation, code, and runtime routing.

1. Naming convention: Use camelCase format — lowercase start, capital letters for subsequent words. Example: deleteUserReport

2. Verb-first structure: Begin the name with an English verb that defines the action. Examples: registerUser, addOrderItem Mindbricks understands common verbs and their tense forms to generate consistent naming in code and routes.

3. Preferred standard verbs: Use standard CRUD verbs (get, list, create, update, delete) whenever applicable, as these trigger automatic RESTful route generation. Use custom verbs only when necessary — e.g., approveRequest instead of updateRequest for clarity of intent.

4. Resource naming: The words following the verb are interpreted as the resource name — usually the Data Object name. Examples:

   • createProduct → resource: product

   • deleteCustomer → resource: customer

   • listActiveProducts → resource: activeProducts

   For list operations, use the plural form — e.g., listInvoices.

Generated Results from Naming

a. Route Path Generation

When standard verbs are used, Mindbricks automatically generates RESTful routes following pluralized resource conventions:

If a non-standard verb is used, the verb itself appears in the route:

You can mix standard and custom verbs:

• updateRequest → /requests/:requestId

• approveRequest → /approverequest/:requestId

b. API Event Names

Mindbricks automatically derives event names from the resource name and the passive form of the verb:

These events are published automatically when raiseApiEvent is enabled.

c. Constant Names in Code

The same API name also influences generated code constants, manager class names, and identifiers. For example, for an API named rateStore, Mindbricks generates:

class RateStoreManager {
  // internal API workflow and actions
}

This pattern ensures semantic clarity across documentation, code, and generated microservice routes — all consistently derived from a single, meaningful API name.

API Description

The description of a Business API should be clearly written in the apiDescription attribute. Do not skip this field — it plays an important role in multiple layers of the Mindbricks ecosystem.

1. Documentation: The API documentation directly uses this description to make the API’s business purpose clear for both human and AI readers.

2. External Tools: Swagger, OpenAPI, Postman, and API-Face documentation all include this description to inform testers and integrators about the API’s intent and behavior.

3. MCP Server Exposure: When the MCP server exposes this Business API as an MCP tool, the same description is published to the client. It must therefore be written clearly and richly enough for MCP clients to understand what the API does and when it should be used.

4. Code Context: The generated service code also embeds this description as a code-level comment, helping developers and reviewers quickly understand the API’s purpose when reading the source files.

In short, apiDescription is not just for documentation — it’s part of the API’s semantic identity across interfaces, code, and AI-driven integrations.

Entity Cache in API Management

Mindbricks can automatically build entity caches in Redis for any Data Object. Entity cache management is explained in detail in the Data Object documentation, but at the API level, it can be selectively enabled or disabled per Business API.

When the option readFromEntityCache is set to true, the API will first attempt to retrieve the target object from the Redis cache. If the cached entity exists, Mindbricks will serve it directly from memory without querying the database, significantly improving response time for frequently accessed records. If the cache does not contain the entity, the system automatically falls back to the database and refreshes the cache afterward.

Raising Events

Each Business API in Mindbricks can emit Kafka events to notify other services or clients about actions and state changes occurring within the system.

At the end of its workflow, every API reaches a publishing milestone where it can emit an event message that includes contextual information and the final output of execution. This feature is controlled by the raiseApiEvent option. When raiseApiEvent is set to true, the API automatically publishes an event after successful completion. For create, update, and delete APIs, this option is enabled by default; for get and list APIs, it is disabled by default unless explicitly activated.

Event Naming Convention

The Kafka topic name for an API event follows this format:

{projectCodeName}-{serviceName}-service-{resourceName}-{apiActionInPassiveForm}

Example:

rentworld-catalog-service-vehicle-created

Verb Rules for Event Names

When get or list APIs are configured to raise events, Mindbricks applies specific wording rules for clarity and linguistic consistency:

• A get API publishes events using the verb “retrieved” instead of “got.” Example: getCustomer → rentworld-customer-service-customer-retrieved

• A list API publishes events using the verb “listed.” Example: listCustomers → rentworld-customer-service-customers-listed

These rules apply only when the action name is exactly get or list. For APIs with other verbs, Mindbricks simply converts the verb into its passive form, preserving its semantic meaning. Examples:

• showCustomers → rentworld-customer-service-customers-shown

• findCustomer → rentworld-customer-service-customer-found

Database-Level Events

In addition to API-level events, Mindbricks can emit database-level events whenever a Data Object operation occurs during workflow execution. For instance, a deleteCustomer API may produce a single API event (customer-deleted) but multiple DB-level events reflecting related operations:

rentworld-service-dbevent-customer-deleted
rentworld-service-dbevent-profile-deleted
rentworld-service-dbevent-account-updated
rentworld-service-dbevent-customeraudit-created

Each DB event publishes the final state of the affected Data Object, ensuring precise synchronization across services, listeners, and analytics pipelines. This behavior is governed by the raiseDbLevelEvents option, which is enabled by default for create, update, and delete APIs.

Understanding Parameters

Every Business API declares its full input shape via requestParameters and — for create / update APIs — its full DB-write map via dataClauseItems. The framework auto-injects values for properties bound to sessionSettings or staticJoin; everything else is the designer's explicit declaration. See the Explicit-mode quick reference at the top of this page for the per-property emit decision tree.

Business API Parameter Definition

A Business API Parameter (of type BusinessApiParameter) declares a single input the API accepts. Each entry in requestParameters is parsed from the incoming request, validated, and transformed before being written into the API context as this.<name>. Parameters can originate from any request source — REST (body, query, urlpath, header), Kafka payload, gRPC input, or other controller types.

"BusinessApiParameter": {
  "name": "String",
  "type": "DataTypes",
  "isArray": "Boolean",
  "isRequired": "Boolean",
  "enumOptions": ["String"],
  "defaultValue": "AnyComplex",
  "httpLocation": "RequestLocations",
  "dataPath": "String",
  "transform": "MScript",
  "hidden": "Boolean",
  "description": "Text"
}

Explanation of Fields

• name The parameter name inside the API context. Its value becomes available as this.<name> during Business API execution and inside dataClauseItems / whereClause MScript. It does not need to match the incoming request key.

• type The expected data type of the parameter, selected from the standard DataTypes enum (e.g., String, ID, Integer, Boolean, Object, Date, Enum). Used for type validation and casting. For Enum, also provide enumOptions[].

• isArray Set when the request shape is array-of-type.

• isRequired Whether the body validator demands the field. If true and the parameter is missing, the API will throw a validation error. When false, an optional defaultValue fires when the caller omits it. This is the API-contract gate; the data property's basicSettings.isRequired is the DB NOT-NULL gate — the two should align (see the anti-patterns list above).

• defaultValue Fallback value when the request omits the parameter and isRequired: false.

• httpLocation Where the parameter is read from in REST APIs: body (default), query, urlpath, header, or session (rare; usually sessionSettings on the data property is the cleaner expression). For other controller types (Kafka, gRPC, Socket), the parameter is part of the request body or payload.

• hidden When true, hides the parameter from API-facing tools such as API-Face, Swagger, or MCP. Hidden parameters are still functional — they're read from the controller and written to the context — but are intentionally excluded from public documentation.

• dataPath A dot-path expression used to locate the parameter value in its source object (e.g., user.email, input.cart.total).

• transform An optional MScript expression that post-processes or normalizes the raw input before it lands in this.<name>. Useful for trimming strings, coercing types, or applying computed defaults. Example:

  this.avatar ?? `https://gravatar.com/avatar/${LIB.common.md5(this.email ?? 'nullValue')}?s=200&d=identicon`
  

• description A human-readable explanation of the parameter's purpose. Always provide a clear, descriptive explanation — it is essential for both human and AI consumers of the API.

DataMapItem — entries in dataClauseItems

Each entry in a create / update API's dataClauseItems[] is a DataMapItem:

"DataMapItem": {
  "name": "String",
  "value": "MScript",
  "description": "Text"
}

• name — the property name on the data object that this entry writes.

• value — an MScript expression. Common shapes:

  Intent	Value shape
  Caller-supplied via the request body	'this.<paramName>'
  System-managed forced literal	"'<literal>'" (string), '42' (number), 'true' (boolean), 'new Date()' (computed)
  Caller-controlled with fallback default	"this.<paramName> || '<default>'"
  Hashed / computed	'this.hashString(this.password)', 'LIB.calc(this.X)'
  Joined-context reference	'this.<contextParameterName>' (when a property's staticJoin sets contextParameterName)

Properties bound via sessionSettings or staticJoin are auto-injected by the framework — do not declare a dataClauseItem for them.