Business API Design Specification -
Create Auctionofferoffer
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
createAuctionOfferOffer
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
createAuctionOfferOffer
Business API is designed to handle a
create
operation on the
AuctionOfferOffer
data object. This operation is performed under the specified
conditions and may include additional, coordinated actions as part
of the workflow.
API Description
Creates a new offer for a fixed-price product, validating acceptOffers, type, eligibility, and product/seller/buyer active. Defaults to PENDING state. Triggers notification event.
API Options
-
Auto Params :
trueDetermines whether input parameters should be auto-generated from the schema of the associated data object. Set tofalseif you want to define all input parameters manually. -
Raise Api Event :
trueIndicates whether the Business API should emit an API-level event after successful execution. This is typically used for audit trails, analytics, or external integrations. The event will be emitted to theauctionofferoffer-createdKafka Topic Note that the DB-Level events forcreate,updateanddeleteoperations 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
ApiCheckOptionto determine whether this is checked during the query or after fetching the instance. -
Read From Entity Cache :
falseIf 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
createAuctionOfferOffer
Business API includes a REST controller that can be triggered via
the following route:
/v1/auctionofferoffers
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
createAuctionOfferOffer
Business API will be registered as a tool on the MCP server within
the service binding.
API Parameters
The
createAuctionOfferOffer
Business API has 13 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
autoParametersoption is enabled. - Custom parameters added by the architect — these can supplement or override the auto-generated parameters.
Parameter Details
| Name | Type | Required | Default | Location | Data Path |
|---|---|---|---|---|---|
auctionOfferOfferId
|
ID
|
No
|
-
|
body
|
auctionOfferOfferId
|
| Description: | This id paremeter is used to create the data object with a given specific id. Leave null for automatic id. | ||||
buyerId
|
ID
|
Yes
|
-
|
session
|
userId
|
| Description: | Buyer making the offer. | ||||
currency
|
String
|
Yes
|
-
|
body
|
currency
|
| Description: | ISO currency (e.g., USD, EUR) for the offer. | ||||
productId
|
ID
|
Yes
|
-
|
body
|
productId
|
| Description: | Product the offer applies to (must be fixed-price, acceptOffers true). | ||||
counterOfferId
|
ID
|
No
|
-
|
body
|
counterOfferId
|
| Description: | References another offer (counter-offer chain). | ||||
counterMessage
|
String
|
No
|
-
|
body
|
counterMessage
|
| Description: | Message accompanying seller's counter-offer (optional). | ||||
counterAmount
|
Double
|
No
|
-
|
body
|
counterAmount
|
| Description: | Counter-offer amount (when offer is COUNTERED). | ||||
offerAmount
|
Double
|
Yes
|
-
|
body
|
offerAmount
|
| Description: | Primary offer amount from buyer. | ||||
message
|
String
|
No
|
-
|
body
|
message
|
| Description: | Message/special notes from buyer (optional). | ||||
sellerId
|
ID
|
Yes
|
-
|
body
|
sellerId
|
| Description: | Seller of the product (recipient of offer; auto-fetched from product). | ||||
status
|
Enum
|
Yes
|
-
|
body
|
status
|
| Description: | Current offer status (e.g., PENDING, ACCEPTED, DECLINED, COUNTERED, EXPIRED, CANCELLED). | ||||
expiresAt
|
Date
|
No
|
-
|
body
|
expiresAt
|
| Description: | When this offer expires (optional). | ||||
respondedAt
|
Date
|
No
|
-
|
body
|
respondedAt
|
| Description: | When the seller (or buyer, for counter-offer) responded/updated the offer status. | ||||
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
createAuctionOfferOffer
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.
Login Requirement
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
Data Clause
Defines custom field-value assignments used to modify or augment
the default payload for
create
and
update
operations. These settings override values derived from the
session or parameters if explicitly provided.", Note that a
default data clause is always prepared by Mindbricks using data
property settings, however any property in the data clause can be
override by Data Clause Settings.
Custom Data Clause Override No custom data clause override configured
Actual Data Clause
The business api will use the following data clause. Note that any calculated value will be added to the data clause in the api manager.
{
id: this.auctionOfferOfferId,
buyerId: this.buyerId,
currency: this.currency,
productId: this.productId,
counterOfferId: this.counterOfferId,
counterMessage: this.counterMessage,
counterAmount: this.counterAmount,
offerAmount: this.offerAmount,
message: this.message,
// sellerId parameter is a static joined paramater
// the value will be read from productListingProduct joint osurce
sellerId: null,
status: this.status,
expiresAt: this.expiresAt,
respondedAt: this.respondedAt,
isActive: true,
_archivedAt: null,
}
Business Logic Workflow
[1] Step : startBusinessApi
Manager initializes context, populates session and request objects, prepares internal structures for parameter handling and workflow execution.
You can use the following settings to change some behavior of this
step.
apiOptions,
restSettings,
grpcSettings,
kafkaSettings,
socketSettings,
cronSettings
[2] Step : readParameters
Manager reads input parameters, normalizes missing values, applies default type casting, and stores them in the API context.
You can use the following settings to change some behavior of this
step.
customParameters,
redisParameters
[3] Step : transposeParameters
Manager transforms parameters, computes derived values, flattens or remaps arrays/objects, and adjusts formats for downstream processing.
[4] Step : checkParameters
Manager executes built-in validations: required field checks, type enforcement, and basic business rules. Prevents operation if validation fails.
[5] Step : checkBasicAuth
Manager performs authentication and authorization checks: verifies session, user roles, permissions, and tenant restrictions.
You can use the following settings to change some behavior of this
step.
authOptions
[6] Step : buildDataClause
Manager constructs the final data object for creation, fills auto-generated fields (IDs, timestamps, owner fields), and ensures schema consistency.
You can use the following settings to change some behavior of this
step.
dataClause
[7] Step : mainCreateOperation
Manager executes the database insert operation, updates indexes/caches, and triggers internal post-processing like linked default records.
[8] Step : buildOutput
Manager shapes the response: masks sensitive fields, resolves linked references, and formats output according to API contract.
[9] Step : sendResponse
Manager sends the response to the client and finalizes internal tasks like flushing logs or updating session state.
[10] Step : raiseApiEvent
Manager triggers API-level events (Kafka, WebSocket, async workflows) as the final internal step.
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
createAuctionOfferOffer
api has got 10 client parameters
| Parameter | Type | Required | Population |
|---|---|---|---|
| currency | String | true | request.body?.currency |
| productId | ID | true | request.body?.productId |
| counterOfferId | ID | false | request.body?.counterOfferId |
| counterMessage | String | false | request.body?.counterMessage |
| counterAmount | Double | false | request.body?.counterAmount |
| offerAmount | Double | true | request.body?.offerAmount |
| message | String | false | request.body?.message |
| status | Enum | true | request.body?.status |
| expiresAt | Date | false | request.body?.expiresAt |
| respondedAt | Date | false | request.body?.respondedAt |
REST Request
To access the api you can use the REST controller with the path POST /v1/auctionofferoffers
axios({
method: 'POST',
url: '/v1/auctionofferoffers',
data: {
currency:"String",
productId:"ID",
counterOfferId:"ID",
counterMessage:"String",
counterAmount:"Double",
offerAmount:"Double",
message:"String",
status:"Enum",
expiresAt:"Date",
respondedAt:"Date",
},
params: {
}
});
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
auctionOfferOffer
object in the respones. However, some properties may be omitted
based on the object's internal logic.
{
"status": "OK",
"statusCode": "201",
"elapsedMs": 126,
"ssoTime": 120,
"source": "db",
"cacheKey": "hexCode",
"userId": "ID",
"sessionId": "ID",
"requestId": "ID",
"dataName": "auctionOfferOffer",
"method": "POST",
"action": "create",
"appVersion": "Version",
"rowCount": 1,
"auctionOfferOffer": {
"id": "ID",
"buyerId": "ID",
"currency": "String",
"productId": "ID",
"counterOfferId": "ID",
"counterMessage": "String",
"counterAmount": "Double",
"offerAmount": "Double",
"message": "String",
"sellerId": "ID",
"status": "Enum",
"status_idx": "Integer",
"expiresAt": "Date",
"respondedAt": "Date",
"isActive": true,
"recordVersion": "Integer",
"createdAt": "Date",
"updatedAt": "Date",
"_owner": "ID"
}
}