Business API Design Specification - `_fetch Listlisting`

A Business API is a set of logical actions centered around a main data object. These actions can range from simple CRUD operations to complex workflows that implement intricate business logic.

While the term “API” traditionally refers to an interface that allows software systems to interact, in Mindbricks a Business API represents a broader concept. It encapsulates a business workflow around a data object, going beyond basic CRUD operations to include rich, internally coordinated actions that can be fully designed and customized.

This document provides an in-depth explanation of the architectural design of the _fetchListListing Business API. It is intended to guide backend architects and developers in maintaining the current design. Additionally, frontend developers and frontend AI agents can use this document to understand how to properly consume this API on the client side.

Main Data Object and CRUD Operation

The _fetchListListing Business API is designed to handle a list operation on the Listing data object. This operation is performed under the specified conditions and may include additional, coordinated actions as part of the workflow.

API Description

System API to fetch list of listing records for frontend application. Auto-generated, not visible in design.

API Options

Auto Params : false Determines whether input parameters should be auto-generated from the schema of the associated data object. Set to false if you want to define all input parameters manually.
Raise Api Event : false 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. Note that the DB-Level events for create, update and delete operations will always be raised for internal reasons.
Active Check : `` Controls how the system checks if a record is active (not soft-deleted or inactive). Uses the ApiCheckOption to determine whether this is checked during the query or after fetching the instance.
Read From Entity Cache : false 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.

API Controllers

A Mindbricks Business API can be accessed through multiple interfaces, including REST, gRPC, WebSocket, Kafka, or Cron. The controllers listed below map the business workflow to a specific interface, enabling consistent interaction regardless of the communication channel.

REST Controller

The _fetchListListing Business API includes a REST controller that can be triggered via the following route:

/v1/_fetchlistlisting

By sending a request to this route using the service API address, you can execute this Business API. Parameters can be provided in multiple HTTP locations, including the URL path, URL query, request body, and request headers. Detailed information about these parameters is provided in the Parameters section.

MCP Tool

REST controllers also expose the Business API as a tool in the MCP, making it accessible to AI agents. This _fetchListListing Business API will be registered as a tool on the MCP server within the service binding.

API Parameters

The _fetchListListing Business API has 14 parameters that must be sent from the controller. Note that all parameters, except session and Redis parameters, should be provided by the client.

Business API parameters can be:

Auto-generated by Mindbricks — inferred from the CRUD type and the property definitions of the main data object when the autoParameters option is enabled.
Custom parameters added by the architect — these can supplement or override the auto-generated parameters.

Filter Parameters

The _fetchListListing api supports 14 optional filter parameters for filtering list results using URL query parameters. These parameters are only available for list type APIs.

`categoryId` Filter

Type: ID
Description: Main category for the listing (categoryLocation:category).
Location: Query Parameter

Usage:

Non-Array Property:

Single value: ?categoryId=<value>
Multiple values: ?categoryId=<value1>&categoryId=<value2>
Null check: ?categoryId=null

Examples:

// Get records with a specific ID
GET /v1/_fetchlistlisting?categoryId=550e8400-e29b-41d4-a716-446655440000

// Get records with multiple IDs (use multiple parameters)
GET /v1/_fetchlistlisting?categoryId=550e8400-e29b-41d4-a716-446655440000&categoryId=660e8400-e29b-41d4-a716-446655440001

// Get records without this field
GET /v1/_fetchlistlisting?categoryId=null

`condition` Filter

Type: Enum
Description: Item condition: new, used, other.
Location: Query Parameter

Usage:

Single value: ?condition=<value> (case-insensitive)
Multiple values: ?condition=<value1>&condition=<value2>
Null check: ?condition=null

Examples:

// Get records with specific enum value
GET /v1/_fetchlistlisting?condition=active

// Get records with multiple enum values (use multiple parameters)
GET /v1/_fetchlistlisting?condition=active&condition=pending

// Get records without this field
GET /v1/_fetchlistlisting?condition=null

`expiresAt` Filter

Type: Date
Description: UTC expiry for listing; after this, listing is automatically expired.
Location: Query Parameter

Usage:

Non-Array Property (Date filtering matches records where the date falls within the specified day, ignoring time portion):

Single date: ?expiresAt=2024-01-15
Multiple dates: ?expiresAt=2024-01-15&expiresAt=2024-01-20
Special operators: ?expiresAt=$today, ?expiresAt=$week, ?expiresAt=$month
Local timezone: ?expiresAt=$ltoday, ?expiresAt=$lweek, ?expiresAt=$leq-2024-01-15, ?expiresAt=$lin-2024-01-15&expiresAt=$lin-2024-01-20
Null check: ?expiresAt=null

Special Date Operators:

$today - Today (server timezone)
$ltoday - Today (user’s local timezone)
$week - This week (server timezone)
$lweek - This week (user’s local timezone)
$month - This month (server timezone)
$leq-<date> - Specific date (user’s local timezone)
$lin-<date> - Date in array (user’s local timezone, use multiple parameters)

Date Formats: Dates can be provided in ISO 8601 format (2024-01-15, 2024-01-15T10:30:00Z) or as timestamps (1705324800000).

Examples:

// Get records created on a specific date
GET /v1/_fetchlistlisting?expiresAt=2024-01-15

// Get records created on multiple dates (use multiple parameters)
GET /v1/_fetchlistlisting?expiresAt=2024-01-15&expiresAt=2024-01-20

// Get records created today (server timezone)
GET /v1/_fetchlistlisting?expiresAt=$today

// Get records created today (user's local timezone)
GET /v1/_fetchlistlisting?expiresAt=$ltoday

// Get records created this week (server timezone)
GET /v1/_fetchlistlisting?expiresAt=$week

// Get records created this week (user's local timezone)
GET /v1/_fetchlistlisting?expiresAt=$lweek

// Get records created this month
GET /v1/_fetchlistlisting?expiresAt=$month

// Get records created on a specific date (user's local timezone)
GET /v1/_fetchlistlisting?expiresAt=$leq-2024-01-15

// Get records created on multiple dates (user's local timezone, use multiple parameters)
GET /v1/_fetchlistlisting?expiresAt=$lin-2024-01-15&expiresAt=$lin-2024-01-20

// Get records without this field
GET /v1/_fetchlistlisting?expiresAt=null

`isPremium` Filter

Type: Boolean
Description: If true, the listing is premium (highlighted/pinned, eligible for special placement).
Location: Query Parameter

Usage:

True: ?isPremium=true
False: ?isPremium=false
Null check: ?isPremium=null

Examples:

// Get records with true value
GET /v1/_fetchlistlisting?isPremium=true

// Get records with false value (or null)
GET /v1/_fetchlistlisting?isPremium=false

// Get records without this field
GET /v1/_fetchlistlisting?isPremium=null

Note: When filtering by false, the query also includes records where the boolean field is null.

`listingType` Filter

Type: Enum
Description: Type of listing (sale, rent, service, etc.).
Location: Query Parameter

Usage:

Single value: ?listingType=<value> (case-insensitive)
Multiple values: ?listingType=<value1>&listingType=<value2>
Null check: ?listingType=null

Examples:

// Get records with specific enum value
GET /v1/_fetchlistlisting?listingType=active

// Get records with multiple enum values (use multiple parameters)
GET /v1/_fetchlistlisting?listingType=active&listingType=pending

// Get records without this field
GET /v1/_fetchlistlisting?listingType=null

`locationId` Filter

Type: ID
Description: Location (categoryLocation:location).
Location: Query Parameter

Usage:

Non-Array Property:

Single value: ?locationId=<value>
Multiple values: ?locationId=<value1>&locationId=<value2>
Null check: ?locationId=null

Examples:

// Get records with a specific ID
GET /v1/_fetchlistlisting?locationId=550e8400-e29b-41d4-a716-446655440000

// Get records with multiple IDs (use multiple parameters)
GET /v1/_fetchlistlisting?locationId=550e8400-e29b-41d4-a716-446655440000&locationId=660e8400-e29b-41d4-a716-446655440001

// Get records without this field
GET /v1/_fetchlistlisting?locationId=null

`premiumExpiry` Filter

Type: Date
Description: UTC date when premium status expires. Null if not premium or not applicable.
Location: Query Parameter

Usage:

Non-Array Property (Date filtering matches records where the date falls within the specified day, ignoring time portion):

Single date: ?premiumExpiry=2024-01-15
Multiple dates: ?premiumExpiry=2024-01-15&premiumExpiry=2024-01-20
Special operators: ?premiumExpiry=$today, ?premiumExpiry=$week, ?premiumExpiry=$month
Local timezone: ?premiumExpiry=$ltoday, ?premiumExpiry=$lweek, ?premiumExpiry=$leq-2024-01-15, ?premiumExpiry=$lin-2024-01-15&premiumExpiry=$lin-2024-01-20
Null check: ?premiumExpiry=null

Special Date Operators:

$today - Today (server timezone)
$ltoday - Today (user’s local timezone)
$week - This week (server timezone)
$lweek - This week (user’s local timezone)
$month - This month (server timezone)
$leq-<date> - Specific date (user’s local timezone)
$lin-<date> - Date in array (user’s local timezone, use multiple parameters)

Date Formats: Dates can be provided in ISO 8601 format (2024-01-15, 2024-01-15T10:30:00Z) or as timestamps (1705324800000).

Examples:

// Get records created on a specific date
GET /v1/_fetchlistlisting?premiumExpiry=2024-01-15

// Get records created on multiple dates (use multiple parameters)
GET /v1/_fetchlistlisting?premiumExpiry=2024-01-15&premiumExpiry=2024-01-20

// Get records created today (server timezone)
GET /v1/_fetchlistlisting?premiumExpiry=$today

// Get records created today (user's local timezone)
GET /v1/_fetchlistlisting?premiumExpiry=$ltoday

// Get records created this week (server timezone)
GET /v1/_fetchlistlisting?premiumExpiry=$week

// Get records created this week (user's local timezone)
GET /v1/_fetchlistlisting?premiumExpiry=$lweek

// Get records created this month
GET /v1/_fetchlistlisting?premiumExpiry=$month

// Get records created on a specific date (user's local timezone)
GET /v1/_fetchlistlisting?premiumExpiry=$leq-2024-01-15

// Get records created on multiple dates (user's local timezone, use multiple parameters)
GET /v1/_fetchlistlisting?premiumExpiry=$lin-2024-01-15&premiumExpiry=$lin-2024-01-20

// Get records without this field
GET /v1/_fetchlistlisting?premiumExpiry=null

`premiumType` Filter

Type: Enum
Description: Which premium package (gold, silver, none, etc.).
Location: Query Parameter

Usage:

Single value: ?premiumType=<value> (case-insensitive)
Multiple values: ?premiumType=<value1>&premiumType=<value2>
Null check: ?premiumType=null

Examples:

// Get records with specific enum value
GET /v1/_fetchlistlisting?premiumType=active

// Get records with multiple enum values (use multiple parameters)
GET /v1/_fetchlistlisting?premiumType=active&premiumType=pending

// Get records without this field
GET /v1/_fetchlistlisting?premiumType=null

`price` Filter

Type: Double
Description: Listing price.
Location: Query Parameter

Usage:

Non-Array Property:

Single value: ?price=<value>
Multiple values: ?price=<value1>&price=<value2>
Range operators: ?price=$lt-<value>, ?price=$lte-<value>, ?price=$gt-<value>, ?price=$gte-<value>, ?price=$btw-<min>-<max>
Null check: ?price=null

Range Operators:

$lt-<value> - Less than
$lte-<value> - Less than or equal
$gt-<value> - Greater than
$gte-<value> - Greater than or equal
$btw-<min>-<max> - Between (inclusive)

Examples:

// Get records with exact value
GET /v1/_fetchlistlisting?price=25

// Get records with multiple values (use multiple parameters)
GET /v1/_fetchlistlisting?price=25&price=30&price=35

// Get records less than value
GET /v1/_fetchlistlisting?price=$lt-30

// Get records greater than or equal to value
GET /v1/_fetchlistlisting?price=$gte-18

// Get records between two values
GET /v1/_fetchlistlisting?price=$btw-100-500

// Get records without this field
GET /v1/_fetchlistlisting?price=null

`status` Filter

Type: Enum
Description: Lifecycle status: pending_review, active, denied, sold, expired, deleted.
Location: Query Parameter

Usage:

Single value: ?status=<value> (case-insensitive)
Multiple values: ?status=<value1>&status=<value2>
Null check: ?status=null

Examples:

// Get records with specific enum value
GET /v1/_fetchlistlisting?status=active

// Get records with multiple enum values (use multiple parameters)
GET /v1/_fetchlistlisting?status=active&status=pending

// Get records without this field
GET /v1/_fetchlistlisting?status=null

`subcategoryId` Filter

Type: ID
Description: Subcategory for the listing, can be null for top-level (categoryLocation:category).
Location: Query Parameter

Usage:

Non-Array Property:

Single value: ?subcategoryId=<value>
Multiple values: ?subcategoryId=<value1>&subcategoryId=<value2>
Null check: ?subcategoryId=null

Examples:

// Get records with a specific ID
GET /v1/_fetchlistlisting?subcategoryId=550e8400-e29b-41d4-a716-446655440000

// Get records with multiple IDs (use multiple parameters)
GET /v1/_fetchlistlisting?subcategoryId=550e8400-e29b-41d4-a716-446655440000&subcategoryId=660e8400-e29b-41d4-a716-446655440001

// Get records without this field
GET /v1/_fetchlistlisting?subcategoryId=null

`title` Filter

Type: String
Description: Listing title, short and clear.
Location: Query Parameter

Usage:

Non-Array Property (Case-Insensitive Partial Matching):

Single value: ?title=<value> (matches any string containing the value, case-insensitive)
Multiple values: ?title=<value1>&title=<value2> (matches records containing any of the values)
Null check: ?title=null

Examples:

// Find records with "john" in the field (case-insensitive partial match)
GET /v1/_fetchlistlisting?title=john
// Matches: "John", "Johnny", "johnson", "McJohn", etc.

// Find records with multiple values (use multiple parameters)
GET /v1/_fetchlistlisting?title=laptop&title=phone&title=tablet
// Matches records containing "laptop", "phone", or "tablet" anywhere in the field

// Find records without this field
GET /v1/_fetchlistlisting?title=null

`userId` Filter

Type: ID
Description: Owner (poster) of the listing (auth:user).
Location: Query Parameter

Usage:

Non-Array Property:

Single value: ?userId=<value>
Multiple values: ?userId=<value1>&userId=<value2>
Null check: ?userId=null

Examples:

// Get records with a specific ID
GET /v1/_fetchlistlisting?userId=550e8400-e29b-41d4-a716-446655440000

// Get records with multiple IDs (use multiple parameters)
GET /v1/_fetchlistlisting?userId=550e8400-e29b-41d4-a716-446655440000&userId=660e8400-e29b-41d4-a716-446655440001

// Get records without this field
GET /v1/_fetchlistlisting?userId=null

`paymentConfirmation` Filter

Type: Enum
Description: An automatic property that is used to check the confirmed status of the payment set by webhooks.
Location: Query Parameter

Usage:

Single value: ?paymentConfirmation=<value> (case-insensitive)
Multiple values: ?paymentConfirmation=<value1>&paymentConfirmation=<value2>
Null check: ?paymentConfirmation=null

Examples:

// Get records with specific enum value
GET /v1/_fetchlistlisting?paymentConfirmation=active

// Get records with multiple enum values (use multiple parameters)
GET /v1/_fetchlistlisting?paymentConfirmation=active&paymentConfirmation=pending

// Get records without this field
GET /v1/_fetchlistlisting?paymentConfirmation=null

Parameter Transformations

Some parameters are post-processed using transform scripts after being read from the request but before validation or workflow execution. Only parameters with a transform script are listed below.

No parameters are transformed in this API.

AUTH Configuration

The authentication and authorization configuration defines the core access rules for the _fetchListListing Business API. These checks are applied after parameter validation and before executing the main business logic.

While these settings cover the most common scenarios, more fine-grained or conditional access control—such as permissions based on object context, nested memberships, or custom workflows—should be implemented using explicit actions like PermissionCheckAction, MembershipCheckAction, or ObjectPermissionCheckAction.

This API requires login (loginRequired = true). Requests from non-logged-in users will return a 401 Unauthorized error. Login is necessary but not sufficient, as additional role, permission, or other authorization checks may still apply.

Ownership Checks

Role and Permission Settings

Absolute roles (bypass all auth checks):
Users with any of the following roles will bypass all authentication and authorization checks, including ownership, membership, and standard role/permission checks:
[superAdmin]

Select Clause

Specifies which fields will be selected from the main data object during a get or list operation. Leave blank to select all properties. This applies only to get and list type APIs.",

Where Clause

Defines the criteria used to locate the target record(s) for the main operation. This is expressed as a query object and applies to get, list, update, and delete APIs. All API types except list are expected to affect a single record.

If nothing is configured for (get, update, delete) the id fields will be the select criteria.

Select By: A list of fields that must be matched exactly as part of the WHERE clause. This is not a filter — it is a required selection rule. In single-record APIs (get, update, delete), it defines how a unique record is located. In list APIs, it scopes the results to only entries matching the given values. Note that selectBy fields will be ignored if fullWhereClause is set.

The business api configuration has no selectBy setting.

Full Where Clause An MScript query expression that overrides all default WHERE clause logic. Use this for fully customized queries. When fullWhereClause is set, selectBy is ignored, however additional selects will still be applied to final where clause.

The business api configuration has no fullWhereClause setting.

Additional Clauses A list of conditionally applied MScript query fragments. These clauses are appended only if their conditions evaluate to true. If no condition is set it will be applied to the where clause directly.

The business api configuration has no additionalClauses setting.

Actual Where Clause This where clause is built using whereClause configuration (if set) and default business logic.

{isActive:true}

List Options

Defines list-specific options including filtering logic, default sorting, and result customization for APIs that return multiple records.

List Sort By Sort order definitions for the result set. Multiple fields can be provided with direction (asc/desc).

[ createdAt desc ]

List Group By Grouping definitions for the result set. This is typically used for visual or report-based grouping.

The list is not grouped.

setAsRead: An optional array of field-value mappings that will be updated after the read operation. Useful for marking items as read or viewed.

No setAsread field-value pair is configured.

Permission Filter Optional filter that applies permission constraints dynamically based on session or object roles. So that the list items are filtered by the user’s OBAC or ABAC permissions.

Permission filter is not active at the moment. Follow Mindbricks updates to be able to use it.

Pagination Options

Contains settings to configure pagination behavior for list APIs. Includes options like page size, offset, cursor support, and total count inclusion.

Business Logic Workflow

[1] Step : startBusinessApi

Initializes context with request and session objects. Prepares internal structures for parameter handling and milestone execution.

You can use the following settings to change some behavior of this step. `apiOptions`, `restSettings`, `grpcSettings`, `kafkaSettings`, `socketSettings`, `cronSettings`

[2] Step : readParameters

Reads request and Redis parameters, applies defaults, and writes them to context for downstream processing.

You can use the following settings to change some behavior of this step. `customParameters`, `redisParameters`

[3] Step : transposeParameters

Transforms and normalizes parameters, derives dependent values, and reshapes inputs for the main list query.

[4] Step : checkParameters

Executes validation logic on required and custom parameters, enforcing business rules and cross-field consistency.

[5] Step : checkBasicAuth

Performs role-based access checks and applies dynamic membership or session-based restrictions.

You can use the following settings to change some behavior of this step. `authOptions`

[6] Step : buildWhereClause

Constructs the main query WHERE clause and applies optional filters or scoped access controls.

You can use the following settings to change some behavior of this step. `whereClause`

[7] Step : mainListOperation

Executes the paginated database query, retrieves the list, and stores results in context for enrichment.

You can use the following settings to change some behavior of this step. `selectClause`, `listOptions`, `paginationOptions`

[8] Step : buildOutput

Assembles the list response, sanitizes sensitive fields, applies transformations, and injects extra context if needed.

[9] Step : sendResponse

Sends the paginated list to the client through the controller.

[10] Step : raiseApiEvent

Triggers optional post-workflow events, such as Kafka messages, logs, or system notifications.

Rest Usage

Rest Client Parameters

Client parameters are the api parameters that are visible to client and will be populated by the client. Note that some api parameters are not visible to client because they are populated by internal system, session, calculation or joint sources.

The _fetchListListing api has 14 filter parameters available for filtering list results. See the Filter Parameters section above for detailed usage examples.

Filter Parameter	Type	Array Property	Description
categoryId	ID	No	Main category for the listing (categoryLocation:category).
condition	Enum	No	Item condition: new, used, other.
expiresAt	Date	No	UTC expiry for listing; after this, listing is automatically expired.
isPremium	Boolean	No	If true, the listing is premium (highlighted/pinned, eligible for special placement).
listingType	Enum	No	Type of listing (sale, rent, service, etc.).
locationId	ID	No	Location (categoryLocation:location).
premiumExpiry	Date	No	UTC date when premium status expires. Null if not premium or not applicable.
premiumType	Enum	No	Which premium package (gold, silver, none, etc.).
price	Double	No	Listing price.
status	Enum	No	Lifecycle status: pending_review, active, denied, sold, expired, deleted.
subcategoryId	ID	No	Subcategory for the listing, can be null for top-level (categoryLocation:category).
title	String	No	Listing title, short and clear.
userId	ID	No	Owner (poster) of the listing (auth:user).
paymentConfirmation	Enum	No	An automatic property that is used to check the confirmed status of the payment set by webhooks.

REST Request

To access the api you can use the REST controller with the path GET /v1/_fetchlistlisting

  axios({
    method: 'GET',
    url: '/v1/_fetchlistlisting',
    data: {
    
    },
    params: {
    
        // Filter parameters (see Filter Parameters section for usage examples)
        // categoryId: '<value>' // Filter by categoryId
        // condition: '<value>' // Filter by condition
        // expiresAt: '<value>' // Filter by expiresAt
        // isPremium: '<value>' // Filter by isPremium
        // listingType: '<value>' // Filter by listingType
        // locationId: '<value>' // Filter by locationId
        // premiumExpiry: '<value>' // Filter by premiumExpiry
        // premiumType: '<value>' // Filter by premiumType
        // price: '<value>' // Filter by price
        // status: '<value>' // Filter by status
        // subcategoryId: '<value>' // Filter by subcategoryId
        // title: '<value>' // Filter by title
        // userId: '<value>' // Filter by userId
        // paymentConfirmation: '<value>' // Filter by paymentConfirmation
            }
  });

REST Response

The API response is encapsulated within a JSON envelope. Successful operations return an HTTP status code of 200 for get, list, update, or delete requests, and 201 for create requests. Each successful response includes a "status": "OK" property. For error handling, refer to the “Error Response” section.

Following JSON represents the most comprehensive form of the listings object in the respones. However, some properties may be omitted based on the object’s internal logic.

{
	"status": "OK",
	"statusCode": "200",
	"elapsedMs": 126,
	"ssoTime": 120,
	"source": "db",
	"cacheKey": "hexCode",
	"userId": "ID",
	"sessionId": "ID",
	"requestId": "ID",
	"dataName": "listings",
	"method": "GET",
	"action": "list",
	"appVersion": "Version",
	"rowCount": "\"Number\"",
	"listings": [
		{
			"id": "ID",
			"attributes": "Object",
			"categoryId": "ID",
			"condition": "Enum",
			"condition_idx": "Integer",
			"contactEmail": "String",
			"contactPhone": "String",
			"currency": "String",
			"description": "Text",
			"expiresAt": "Date",
			"favoriteCount": "Integer",
			"isPremium": "Boolean",
			"listingType": "Enum",
			"listingType_idx": "Integer",
			"locationId": "ID",
			"_paymentConfirmation": "String",
			"premiumExpiry": "Date",
			"premiumType": "Enum",
			"premiumType_idx": "Integer",
			"price": "Double",
			"status": "Enum",
			"status_idx": "Integer",
			"subcategoryId": "ID",
			"title": "String",
			"userId": "ID",
			"viewsCount": "Integer",
			"paymentConfirmation": "Enum",
			"paymentConfirmation_idx": "Integer",
			"isActive": true,
			"recordVersion": "Integer",
			"createdAt": "Date",
			"updatedAt": "Date",
			"_owner": "ID",
			"mainCategory": [
				{
					"description": "Text",
					"icon": "String",
					"name": "String",
					"parentCategoryId": "ID",
					"slug": "String",
					"sortOrder": "Integer"
				},
				{},
				{}
			],
			"location": [
				{
					"city": "String",
					"country": "String",
					"district": "String",
					"latitude": "Double",
					"longitude": "Double",
					"postalCode": "String"
				},
				{},
				{}
			],
			"subCategory": [
				{
					"description": "Text",
					"icon": "String",
					"name": "String",
					"parentCategoryId": "ID",
					"slug": "String",
					"sortOrder": "Integer"
				},
				{},
				{}
			],
			"user": [
				{
					"fullname": "String"
				},
				{},
				{}
			]
		},
		{},
		{}
	],
	"paging": {
		"pageNumber": "Number",
		"pageRowCount": "NUmber",
		"totalRowCount": "Number",
		"pageCount": "Number"
	},
	"filters": [],
	"uiPermissions": []
}

Business API Design Specification - _fetch Listlisting

Main Data Object and CRUD Operation

API Description

API Options

API Controllers

REST Controller

MCP Tool

API Parameters

Filter Parameters

categoryId Filter

condition Filter

expiresAt Filter

isPremium Filter

listingType Filter

locationId Filter

premiumExpiry Filter

premiumType Filter

price Filter

status Filter

subcategoryId Filter

title Filter

userId Filter

paymentConfirmation Filter

Parameter Transformations

AUTH Configuration

Login Requirement

Ownership Checks

Role and Permission Settings

Select Clause

Where Clause

List Options

Pagination Options

Business Logic Workflow

[1] Step : startBusinessApi

You can use the following settings to change some behavior of this step. apiOptions, restSettings, grpcSettings, kafkaSettings, socketSettings, cronSettings

[2] Step : readParameters

You can use the following settings to change some behavior of this step. customParameters, redisParameters

[3] Step : transposeParameters

[4] Step : checkParameters

[5] Step : checkBasicAuth

You can use the following settings to change some behavior of this step. authOptions

[6] Step : buildWhereClause

You can use the following settings to change some behavior of this step. whereClause

[7] Step : mainListOperation

You can use the following settings to change some behavior of this step. selectClause, listOptions, paginationOptions

[8] Step : buildOutput

[9] Step : sendResponse

[10] Step : raiseApiEvent

Rest Usage

Rest Client Parameters

REST Request

REST Response

Business API Design Specification - `_fetch Listlisting`

`categoryId` Filter

`condition` Filter

`expiresAt` Filter

`isPremium` Filter

`listingType` Filter

`locationId` Filter

`premiumExpiry` Filter

`premiumType` Filter

`price` Filter

`status` Filter

`subcategoryId` Filter

`title` Filter

`userId` Filter

`paymentConfirmation` Filter

You can use the following settings to change some behavior of this step. `apiOptions`, `restSettings`, `grpcSettings`, `kafkaSettings`, `socketSettings`, `cronSettings`

You can use the following settings to change some behavior of this step. `customParameters`, `redisParameters`

You can use the following settings to change some behavior of this step. `authOptions`

You can use the following settings to change some behavior of this step. `whereClause`

You can use the following settings to change some behavior of this step. `selectClause`, `listOptions`, `paginationOptions`