Business API Design Specification -
Callback Premiumsubscriptionpayment
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
callbackPremiumsubscriptionPayment
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
callbackPremiumsubscriptionPayment
Business API is designed to handle a
update
operation on the
Premiumsubscription
data object. This operation is performed under the specified
conditions and may include additional, coordinated actions as part
of the workflow.
API Description
Refresh payment values by gateway webhook call for premiumsubscription
API Options
-
Auto Params :
falseDetermines 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 thepremiumsubscriptionpayment-calledbackKafka 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
callbackPremiumsubscriptionPayment
Business API includes a REST controller that can be triggered via
the following route:
/v1/callbackpremiumsubscriptionpayment
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
callbackPremiumsubscriptionPayment
Business API will be registered as a tool on the MCP server within
the service binding.
API Parameters
The
callbackPremiumsubscriptionPayment
Business API has 1 parameter 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 |
|---|---|---|---|---|---|
premiumsubscriptionId
|
ID
|
Yes
|
-
|
body
|
premiumsubscriptionId
|
| Description: | The order id parameter that will be read from webhook callback params | ||||
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.
-
premiumsubscriptionId:
this.premiumsubscriptionId =
this.paymentCallbackParams?.orderId
AUTH Configuration
The
authentication and authorization configuration
defines the core access rules for the
callbackPremiumsubscriptionPayment
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 is public and can be accessed without
login (loginRequired = false).
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]
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.
{$and:[{id:this.premiumsubscriptionId},{isActive:true}]}
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.
An update data clause populates all update-allowed properties of a data object, however the null properties (that are not provided by client) are ignored in db layer.
Custom Data Clause Override
{
status: this.status,
updatedAt: new Date(),
_paymentConfirmation: this._paymentConfirmation,
}
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.
{
status: this.status,
updatedAt: new Date(),
// _paymentConfirmation parameter is closed to update by client request
// include it in data clause unless you are sure
_paymentConfirmation: this._paymentConfirmation,
}
Business Logic Workflow
[1] Step : startBusinessApi
Manager initializes context, prepares request and session objects, and sets up 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
Manager reads parameters from the request or Redis, applies defaults, and writes them into context for downstream milestones.
You can use the following settings to change some behavior of this
step.
customParameters,
redisParameters
[3] Action : verifyPaymentWebhook
Action Type:
VerifyWebhookAction
Verify a providers webhook call with the secret signature and read the params, write the callback parameters to the context. Only stripe webhooks is supported for now.
class Api {
// Code for VerifyWebhookAction
async verifyPaymentWebhook() {
const secretKey = null;
const stripeGateway = this.checkoutManager.paymentGate;
const result = await stripeGateway.webhookController(this.request);
if (result.statusLiteral == "unhandled") {
throw new BadRequestError(
`Unhandled stripe webhook event [${result.eventType}]`,
);
}
return result;
}
}
[4] Step : transposeParameters
Manager executes parameter transform scripts and derives any helper values or reshaped payloads into the context.
[5] Step : checkParameters
Manager validates required parameters, checks ID formats (UUID/ObjectId), and ensures all preconditions for update are met.
[6] Step : checkBasicAuth
Manager performs login verification, role, and permission checks, enforcing tenant and access rules before update.
You can use the following settings to change some behavior of this
step.
authOptions
[7] Step : buildWhereClause
Manager constructs the WHERE clause used to identify the record to update, applying ownership and parent checks if necessary.
You can use the following settings to change some behavior of this
step.
whereClause
[8] Step : fetchInstance
Manager fetches the existing record from the database and writes it to the context for validation or enrichment.
[9] Step : checkInstance
Manager performs instance-level validations, including ownership, existence, lock status, or other pre-update checks.
[10] Action : doPaymentCallback
Action Type:
CheckoutAction
Refresh payment by Stripe platform webhook, the payment operation data in the gateway server will be given by webhook call and the application payment tickets and order status will be refreshed according to the server.
class Api {
getOrderId() {
return this.premiumsubscriptionId;
}
getPaymentStatusTopic(actionType) {
switch (actionType) {
case "started":
return "linkedin-profile-service-premiumsubscriptionpaymentstatus-started";
case "updated":
return "linkedin-profile-service-premiumsubscriptionpaymentstatus-updated";
case "succeeded":
return "linkedin-profile-service-premiumsubscriptionpaymentstatus-succeeded";
case "failed":
return "linkedin-profile-service-premiumsubscriptionpaymentstatus-failed";
}
}
async checkoutUpdated(statusLiteral) {
switch (statusLiteral) {
case "started":
await this.checkoutStarted();
break;
case "canceled":
await this.checkoutCanceled();
break;
case "failed":
await this.checkoutFailed();
break;
case "success":
await this.checkoutDone();
break;
default:
await this.checkoutFailed();
break;
}
}
async checkoutStarted() {
this.status = "pending";
this._paymentConfirmation = "processing";
this.raisePaymentStatusEvent("started");
}
async checkoutCanceled() {
this.status = "cancelled";
this._paymentConfirmation = "canceled";
this.raisePaymentStatusEvent("failed");
}
async checkoutFailed() {
this.status = "declined";
this._paymentConfirmation = "canceled";
this.raisePaymentStatusEvent("failed");
}
async checkoutDone() {
this.status = "completed";
this._paymentConfirmation = "paid";
this.raisePaymentStatusEvent("succeeded");
}
getCheckoutParameters(userParams) {
const description = `Making subscription for this userId: ${this.premiumsubscription.userId} with profileId: ${this.premiumsubscription.profileId}`;
return {
userId: this.session._USERID,
fullname: this.session.fullname,
email: this.session.email,
description,
amount: this.premiumsubscription.price,
currency: this.premiumsubscription.currency,
orderId: this.premiumsubscription.id,
metadata: {
order: "Profile-Premiumsubscription-order",
orderId: this.premiumsubscription.id,
checkoutName: "premiumsubscription",
},
storeCard: userParams?.storeCard,
paymentUserParams: userParams,
bodyParams: this.bodyParams,
};
}
async doPaymentCallback() {
// Handle Checkout Action
try {
if (!this.checkoutManager) {
throw new Error(
"This dboject is not an order object. So auto-checkout process can not be started.",
);
}
this.paymentResult =
await this.checkoutManager.processCheckoutCallbackResult(
this.paymentCallbackParams,
);
} catch (err) {
if (err instanceof PaymentGateError) {
this.paymentResult = err.serializeError();
//**errorLog
} else throw err;
}
return this.paymentResult;
}
}
[11] Step : buildDataClause
Manager prepares the data clause for the update, applying transformations or enhancements before persisting.
You can use the following settings to change some behavior of this
step.
dataClause
[12] Step : mainUpdateOperation
Manager executes the update operation with the WHERE and data clauses. Database-level events are raised if configured.
[13] Step : buildOutput
Manager assembles the response object from the update result, masking fields or injecting additional metadata.
[14] Step : sendResponse
Manager sends the response back to the controller for delivery to the client.
[15] Step : raiseApiEvent
Manager triggers API-level events, sending relevant messages to Kafka or other integrations if configured.
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
callbackPremiumsubscriptionPayment
api has got 1 client parameter
| Parameter | Type | Required | Population |
|---|---|---|---|
| premiumsubscriptionId | ID | true | request.body?.premiumsubscriptionId |
REST Request
To access the api you can use the REST controller with the path POST /v1/callbackpremiumsubscriptionpayment
axios({
method: 'POST',
url: '/v1/callbackpremiumsubscriptionpayment',
data: {
premiumsubscriptionId:"ID",
},
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
premiumsubscription
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": "premiumsubscription",
"method": "POST",
"action": "update",
"appVersion": "Version",
"rowCount": 1,
"premiumsubscription": {
"id": "ID",
"profileId": "ID",
"currency": "String",
"status": "String",
"price": "Double",
"userId": "ID",
"_paymentConfirmation": "Enum",
"_paymentConfirmation_idx": "Integer",
"isActive": true,
"recordVersion": "Integer",
"createdAt": "Date",
"updatedAt": "Date",
"_owner": "ID"
},
"paymentResult": {
"paymentTicketId": "ID",
"orderId": "ID",
"paymentId": "String",
"paymentStatus": "Enum",
"paymentIntentInfo": "Object",
"statusLiteral": "String",
"amount": "Double",
"currency": "String",
"success": true,
"description": "String",
"metadata": "Object",
"paymentUserParams": "Object"
}
}