Mono Marketplace Setup Configurations
1. Installing the Marketplace Dashboard Application on ACC
The Marketplace Dashboard application needs to be installed on ACC. To do this, log in with your username and password at https://console.akinoncloud.com.
From the menu, navigate to the App Store, select the Mono application where sales will be made, then choose the relevant project and proceed with the installation.
After the installation, navigate to My Applications from the left menu, select the relevant application, and enter its application page. Once the necessary build and deployment processes are completed, the Mono Marketplace Dashboard application will appear in the left menu of Omnitron, ready for use.
After the installation, the menu will appear as shown in the screenshot.
2. Defining the Sales Channel
After the deployment of the application is completed in ACC, a sales channel will be automatically created in Omnitron. The required fields within this sales channel must be filled in.
You can access the sales channel via Omnitron > Settings > Sales Channels.
Channel Name
Name of the sales channel.
Mono
Automatically created.
Required (do not change)
Catalog Name
Catalog name for Mono (brand-specific).
Mono_Catalog
Automatically created.
Required (do not change)
Channel Type
Type of the channel (appears in dropdown).
Sales Channel
Automatically created.
Required (do not change)
Status
Channel must be active to operate.
Inactive
Defaults to inactive.
Required
Schema Type
Defines stored settings schema (key/label/required/data_type). Minimal schema auto-generated; you may add non-breaking fields.
{"base_url": {"key":"base_url",...}}
Auto-filled.
Required (keep existing keys)
Base Url
Mono API base endpoint.
https://example.com/
Pre-filled default.
Required
Access Token
Static token used in requests (see auth docs).
default
Obtained from Mono.
Required
Category Ids
Main category ids list.
f8aeb10e-...
Blank by default.
Required
Feature Flags
Enable/disable flows; unused flows must exist as false (see Section 9).
{"get_orders":false,...}
Defaults all false.
Required
Cargo Company Mapping
Maps incoming cargo slug to Omnitron shipping company (used if send_shipping_info inactive).
{"default":"3","yurtici":"2"}
Default key provided.
Required
Use Cargo Label
Generate shipping label (PDF) when fetching order if brand not managing shipping.
Inactive
Blank by default.
Optional
Use Neighborhood
Use neighborhood (mahalle) info in address creation.
Inactive
Enable if ERP requires.
Optional
Order Number Format
Custom format; blank uses {orderNumber}-{id}.
MONO-{orderNumber}-{id}
Blank by default.
Optional
Default Reason Id
Fallback refund reason id.
5
Blank by default.
Required
Refund Reason Mapping
Maps Mono refund reason ids to Omnitron ids.
{"f3909f...":"7"}
Blank by default.
Optional
Refund Start Date
Initial datetime to begin refund fetch (%Y-%m-%dT%H:%M:%SZ).
2023-07-01T00:00:00Z
Blank by default.
Optional
Failed Integration
Penalty config for failed ops (Section 3). RETRY_INTERVAL (s wait), EXPIRATION_DATE (s lifetime), MAX_RETRY_COUNT (attempt cap), sent_to_remote (h result window).
{"order":{"RETRY_INTERVAL":28800,"EXPIRATION_DATE":57601,"MAX_RETRY_COUNT":3},"DEFAULT":{"RETRY_INTERVAL":28800,"EXPIRATION_DATE":57601,"MAX_RETRY_COUNT":3},"product":{"RETRY_INTERVAL":28800,"EXPIRATION_DATE":57601,"MAX_RETRY_COUNT":3},"productprice":{"RETRY_INTERVAL":28800,"EXPIRATION_DATE":57601,"MAX_RETRY_COUNT":3},"productstock":{"RETRY_INTERVAL":28800,"EXPIRATION_DATE":57601,"MAX_RETRY_COUNT":3},"sent_to_remote":{"EXPIRATION_HOUR":1}}
Pre-filled.
Required
Send Shipping Info
Whether brand manages shipping.
Inactive
Inactive → Mono manages.
Optional
Cancellation Reason Id
Reason id for cancelled orders.
4
Blank by default.
Required
Cancel Reason Mapping
Maps Mono cancel reason ids to Omnitron ids.
{"f3909f...":"1"}
Blank by default.
Optional
Reject Item Reason
Reason used when rejecting refund line.
Damaged
Blank by default.
Optional
Attribute Set Strategy
Determines attribute set (do not change).
CategoryNode
Pre-filled.
Required
Use Channel ID In Address Mapping
Prefixes address keys with channel id.
Inactive
Blank by default.
Optional
Buffer Stock
Quantity deducted from actual stock.
3
Blank by default.
Optional
Waybill Option
Config for waybill number injection on shipped/delivered.
{"enabled":true,"default":"999"}
{"enabled":false,"default":""}
Optional
Send Cancel Reason ID
Reason id used when sending cancellations created in Omnitron.
10
Must differ from other cancel reason ids.
Optional
Get Discount Amount
Include discount data while fetching orders.
Inactive
Inactive by default.
Optional
3. Failed Integration Settings
Records that encounter errors in the integration process are temporarily put on hold (penalty). The values for RETRY_INTERVAL and EXPIRATION_DATE are durations expressed in seconds.
RETRY_INTERVAL: Wait time (seconds) before the next retry attempt.EXPIRATION_DATE: Total duration (seconds) added to the first failure time. After this duration the resulting absolute timestamp (expiration_date) is passed, no further retries occur. This is a duration, not a stored absolute timestamp.MAX_RETRY_COUNT: Upper limit of total allowed attempts for a single failed record (including the first failed attempt). Condition check:retry_count < MAX_RETRY_COUNT.sent_to_remote.EXPIRATION_HOUR: In channel configuration (FAILED_INTEGRATION.sent_to_remote.EXPIRATION_HOUR), the maximum hour window during which the remote system (Mono) response is awaited.BatchRequestentries still insent_to_remoteor ongoing beyond this window are marked fail (seefinalize_sent_to_remote_batch_requests).
EXPIRATION_DATE and MAX_RETRY_COUNT jointly restrict retry behavior:
MAX_RETRY_COUNT: Stops retries once the limit is reached even if time remains.EXPIRATION_DATE: Stops retries once the time window has elapsed even if the count limit is not reached.
Effective retry condition: (retry_count < MAX_RETRY_COUNT) AND (expiration_date is None OR current_time < expiration_date).
An integration is eligible for retry only if retry_count < MAX_RETRY_COUNT and (if set) current time is before expiration_date. Retries stop when either the maximum attempt count is reached or the end timestamp is passed.
Adjusting values based on error volume: For high error rate processes (e.g. frequently failing product or stock updates), use lower RETRY_INTERVAL, MAX_RETRY_COUNT, and EXPIRATION_DATE so faulty records do not remain long and block others. For low error rates, increase these to allow more retry chances. Optimize according to operational needs and error analysis. In critical flows, as error volume rises, aggressively reduce retry duration and count to preserve stability.
Changes to these values apply to subsequently created FailedIntegration records. Example: if a SKU stock update fell into penalty with a 3‑hour interval and the interval is changed to 2 hours, the existing record still retries after 3 hours; if it fails again the new record uses the 2‑hour interval.
Default Format:
"order":
{
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 3
},
"DEFAULT":
{
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 3
},
"product":
{
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 3
},
"productprice":
{
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 3
},
"productstock":
{
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 3
},
"sent_to_remote":
{
"EXPIRATION_HOUR": 1
}
}Example for product settings when product count is between 100–10,000:
...
"product":
{
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 2
}
...If product count is between 100,000–1,000,000:
...
"product":
{
"RETRY_INTERVAL": 57600,
"EXPIRATION_DATE": 105200,
"MAX_RETRY_COUNT": 4
}
...For example: If a product hits an error while sending to Mono (missing stock, price data, incomplete mapping, not found, or no response from Mono within the sent_to_remote time), the record is penalized under the current failed integration settings and will not be resent during the penalty window. Additionally, BatchRequest entries awaiting remote response that exceed sent_to_remote.EXPIRATION_HOUR without a reply are automatically marked fail. This prevents errored or unresponsive operations from blocking healthy records.
4. Creation of Category Tree and Development of Attributes for Sales Channel
The category tree is fetched according to the added Category Ids within the sales channel.
After the category tree is pulled into Omnitron, it can be viewed under the Category Management section when the relevant Mono is selected in Sales Channels.
After this process is successfully completed (which can be monitored via logs), the flow responsible for fetching attributes will run. Once the attribute-related operations are finished (i.e., the Default Attributes flow has run and completed successfully), you can proceed to the next steps.
5. Marketplace Mapping
After completing the category tree fetching step, users need to perform category mappings through the Mapper.The Akinon Mapper function within Omnitron enables users to configure and manage the attribute values of products they want to sell on marketplace sales channels according to each marketplace’s requirements. Additionally, it provides the ability to verify whether the attributes and attribute values are correct before the products go live for sale.
You can find detailed documentation about the Mapper and the necessary configurations to be done within the Mapper in Mapper tutorial.
Examples of custom mappings you can create for Mono are available in Mono Marketplace Mapper Definitions.
6. Adding Products to the Category Tree
Products need to be added to the relevant category tree on the Mono side. Each product should be assigned to only one category; otherwise, an error will occur during submission.
7. Defining Screens
When the Mono marketplace application is installed on the relevant brand’s Omnitron, it appears as Mono in the left-side menu.
7.1. Dashboard Screen
Dashboard data related to the Mono marketplace application is displayed on this screen.
TOTAL SKUs IN THE CATALOG The number of SKUs with simple product type and active status added to the relevant catalog.
NUMBER OF SKUs ON SALE The number of SKUs that have been sent to the marketplace and are currently on sale.
TOTAL SKU DIFFERENCE The number of SKUs added to the catalog but not on sale in the marketplace. This section compares the sellable products in Omnitron with the products on sale in the marketplace. It considers products in Omnitron that have a price, stock greater than zero, a category, a product image, and are included in the catalog.
NUMBER OF SKUs WITH PRICE DIFFERENCES THAT HAVE BEEN CORRECTED The number of SKUs with price differences between Omnitron and the marketplace. If there is a difference, a task has been run to correct these discrepancies, and the differences have been resolved.
TOTAL STOCK COUNT IN THE CATALOG The total stock count of all products in the marketplace catalog.
TOTAL STOCK COUNT The total stock count of products currently on sale in the marketplace.
TOTAL STOCK DIFFERENCE The stock count of products that are in the catalog but not on sale in the marketplace.
NUMBER OF SKUs WITH STOCK DIFFERENCES The number of SKUs with stock differences between Omnitron and the marketplace. If there is a difference, a task has been run to correct these discrepancies, and the differences have been resolved.
7.2. Monitoring Screen
This screen displays logs and reports.
7.2.1. Log Screen
The logs of the flows are displayed on this screen.
Category Node The flow that pulls the entire tree structure of main categories entered in the channel settings into Omnitron.
Category Attribute and Values The flow that pulls the category attributes entered in the channel settings into Omnitron.
Default Attributes The flow that prepares predefined fields (like remote_id, title, etc.) for the mapping process during product sending.
Product The flow that sends products entered in Omnitron to the marketplace.
Product Delete The flow that removes products taken out from the catalog in Omnitron from sale on the marketplace.
Stock The flow that sends updated stock information of products updated in Omnitron to the marketplace.
Price The flow that sends updated price information of products updated in Omnitron to the marketplace.
Order Create The flow that pulls orders from the marketplace into Omnitron.
Order Update The flow that updates orders on the marketplace when their status, invoice, or shipping tracking number is updated in Omnitron.
Order Cancel The flow that updates the status of canceled orders on Omnitron when they are canceled on the marketplace.
Order Refund The flow that updates the status of refunded orders on Omnitron when they are refunded on the marketplace.
Updated Orders The flow that updates order statuses on Omnitron when order statuses change on the marketplace.
Approve / Reject Refund Order The flow that sends the approval/rejection status of refunds approved/rejected in Omnitron to the marketplace.
Split Packages The flow that transmits order splitting requests coming from Omnitron or another OMS system to the marketplace.
Compare Attributes The flow that updates the statuses of category attributes changed on the marketplace in Omnitron.
Send Cancel Order Items The flow that updates the status of canceled orders on the marketplace when they are canceled in Omnitron.
7.2.2. Report Screen
This screen provides reports on products that are added to the catalog in Omnitron but are not listed for sale on Mono. It highlights discrepancies between the price and stock information in Mono and the corresponding data in Omnitron.
7.3. Alarm Screen
Creating Alarms and Notifications The Marketplace Dashboard is an advanced automation platform designed to facilitate e-commerce integrations. Alarms and notifications play a vital role in informing users about critical events such as integration errors, data delays, and successful completions. Thanks to real-time alerts, users can quickly detect and resolve integration issues, ensuring smooth operation of e-commerce processes. This contributes to providing the best shopping experience to end customers.
Benefits of Alarms and Notifications
Real-Time Issue Detection: Alarms instantly detect integration errors, ensuring accurate data flow between systems.
Proactive Problem Resolution: Alarms enable timely intervention for integration issues, minimizing downtime and operational impact.
Increased Data Integrity: Alarms prevent data delays or interruptions, supporting consistent and accurate data processing.
Optimized Customer Experience: Quick resolution of integration problems keeps order, stock, and product information always up to date, providing customers with a seamless shopping experience.
Improved Operational Efficiency: Users are informed about critical events and can focus on strategic tasks thanks to alarms.
Data-Driven Decision Making: Alarms offer valuable insights to optimize integration processes.
Reduced Downtime: Early detection of issues minimizes system outages and prevents revenue loss.
Customizable Alerts: Akinon Marketplace Dashboard allows flexible alarm customization based on business needs.
Seamless Cross-Platform Communication: Alarms facilitate communication and synchronization between different e-commerce systems.
By leveraging alarms in the Akinon Marketplace Dashboard, users can effectively monitor and manage e-commerce integrations, enabling a reliable, efficient, and customer-centric shopping experience.
Steps to Create Alarms and Notifications
Step 1: Access Alarm and Notification Settings The Marketplace Dashboard is not a standalone product opened via a separate URL. To access it, first go to the Sales Channels menu on the left side of Omnitron, click on the relevant marketplace, and then select Marketplace Operations from the dropdown menu.
Step 2: Create a New Alarm and Notification Rule Click the + New Alarm button located at the top right corner of the “Alarms” screen.
On the opened settings page, select a Flow Name from the dropdown list.
Set the alarm conditions based on specific criteria such as error rate, flow duration, time interval, and metric value.
Select a notification channel and add the email addresses of the individuals or teams who will receive the notifications. (There is no limit on the number of email addresses.)
Step 3: Saving the Alarm and Notification Rule After successfully configuring the alarm rule, click the “Save” button to save the alarm.
Thanks to the power of alarms and notifications in Akinon Marketplace Dashboard, e-commerce integrations become more efficient. Real-time monitoring enables immediate intervention in issues, maintaining data accuracy and ensuring a flawless customer experience. Customizable alerts allow teams to stay informed and make data-driven decisions.
Error Rate: If the number of errors within the specified time interval exceeds the defined limit, the alarm is triggered.
Average Flow Time: If the average processing time of the flow within the specified time interval exceeds the set duration, the alarm is triggered.
7.4. Trigger Screen
This screen is used for triggering flows.
8. Troubleshooting Steps
The following steps should be followed for errors encountered in the logs:
“Stock data not found” error indicates that the product stock data is missing. Stock data must be added for the related product.
“Price data not found” error indicates that the product price data is missing. Price data must be added for the related product.
“... attribute is required” error indicates missing mapping for the related attribute. Mapping should be done as described in Section 5 (Marketplace Mapping).
“Unreported order of ERP can not be canceled” error means the order has not yet been sent to the ERP. The order must be transmitted to the ERP before cancellation can proceed.
“Address is not valid. channel: 137 code: 137_Merkez model: Township city id: .., city name: …” error indicates that the Township in the order address needs to be mapped.
Product triggering from the dashboard only triggers create operations. To trigger product updates, use the “Update Bulk Product Version Date” option in the channel settings at the top right and upload a CSV file via the “Update by file upload” section.
For triggering flows, refer to this document: Flow Trigger Document.
Stopping the shipment of faulty products or resending products that failed to be sent;
Faulty products are retried for a certain period according to the rules defined in the Failed Integration settings in the channel configuration. Products for which retry attempts have stopped according to this rule require manual triggering.
To remove products that have fallen into this state from the penalty queue, go to Omnitron’s right menu, select Settings > Sales Channels, then select the relevant channel. On the resulting page, use the Update by Uploading Files button located to the left of “Delete Bulk Failed Integration” at the top right to upload a CSV file.
If too many faulty products accumulate in the queue, since processing is done in batches of 50, the queue may not proceed to the next products. There are two solutions for this:
Promptly fix errors related to mapping, catalog, stock, price, etc., and then trigger the process again by uploading a CSV file.
Properly configure the Failed Integration settings in the channel configuration with appropriate time intervals.
For the error "Failed to suggest product to catalog," if the issue is related to attribute values, the Category Attributes flow should be run to fetch the updated attribute values. If needed, the Compare Attributes flow should also be executed.
Errors encountered after CSV upload:
sku cannot identify please check your csv file. Header value should be set this: sku This error occurs when the first row of the CSV file is not set as "sku". The CSV file must be created according to the template provided on the trigger screen.
The relevant SKU not exists in Omnitron. Request URL: {url} This error occurs if the relevant SKU does not exist in Omnitron.
The relevant record is processing in another queue, LocalBatchId: {local_batch_id} This error appears when a product that is already in the sending process is triggered again. It is necessary to check the product logs and wait for the flow with "Waiting" status to finish. After the process completes, the relevant log can be filtered by SKU to check the final status.
The relevant record is not in queue. The item may have been penalized or check if the product is saleable This error occurs if the product is inactive or not in the catalog.
For the Order Update (send_update_orders) flow and unresolved orders on the MPD side, the following applies:
If there is an ongoing or opened return process for the order, it will not be updated.
The shipping number value will only be sent if “Send Shipping Info” is actively checked. For details, refer to the “Feature Flags” section.
The order status cannot be updated retroactively. Therefore, manual intervention in the flows should be avoided.
9. Feature Flags
The default frequency values for operation are as shown in the table below. These values can be modified by the Marketplace team.
get_orders
This ensures that orders with the "Preparing" status on the Mono side are pulled into Omnitron, going 12 hours back from the flow's runtime. Before activating this flag, the settings mentioned in the 2nd section (Sales Channel Definition) — Use Neighborhood, Use Channel Id In Address Mapping, Use Cargo Label, Cargo Company Mapping, Send Shipping Info, Order Number Format, and Get Discount Amount — should be properly configured.
It runs every 5 minutes.
get_cancel_orders
The flow fetches claims marked as "cancel completed" from the Mono side going back 12 hours from the flow's execution time and processes cancellations in Omnitron, ensuring that the maximum number of cancellation plans is 6. Before activating this flag, the Cancellation Reason Id and Cancel Reason Mapping settings under the second heading (Sales Channel Definition) above must be properly configured.
It runs every 5 minutes.
get_refund_orders
The flow retrieves claims with refund status that are in “open” or “waiting” states from the Mono side, processes the claim lines, and creates refund requests in Omnitron. Before activating this flag, the Default Reason Id, Refund Reason Mapping, and Refund Start Date settings under the second heading (Sales Channel Definition) above must be properly configured.
It runs every 5 minutes.
send_update_orders
It enables sending the order statuses (“Preparing”, “Shipped”, “Delivered”), invoice information (invoice_number, invoice_date, e_archive_url), and tracking details (tracking_number, tracking_url, shipped_date) to Mono. Before activating this flag, the Send Shipping Info and Waybill Option settings under the second heading (Sales Channel Definition) above must be properly configured.
With this flow, the invoice and order status are updated. The tracking number is sent only if Send Shipping Info is enabled.
It runs every 5 minutes.
send_split_packages
Necessary details can be found in the document at the link: Requirements and settings needed for the order splitting flow.
It works through the trigger sent from the OMS externally via outbound.
product
It enables the sending of products that have been added or updated in the catalog, along with their price and stock information, to Mono. Before activating this flag, the Buffer Stock setting in the section above (Sales Channel Definition) must be properly configured.
It runs every 5 minutes.
delete_product
It ensures that the stock of products removed from the catalog is set to zero on the Mono side.
It runs every 5 minutes.
price
It ensures that the prices of products that need to be updated are sent to Mono.
It runs every 5 minutes.
stock
It ensures that the stock quantities of products that need to be updated are sent to Mono. Before activating this flag, the Buffer Stock setting in the section 2 (Sales Channel Configuration) above must be properly configured.
It runs every minute.
get_updated_orders
When shipping processes are managed by Mono, this flow retrieves orders that have changed to “Shipped” or “Delivered” status on the Mono side, going back 24 hours from the flow’s run time, and updates the status and tracking_number (for “Shipped” status) on an item basis in Omnitron. Before activating this flag, the Send Shipping Info setting under the second main heading (Sales Channel Definition) above must be configured properly.
It runs every morning at 06:00.
send_refund_order_status
It allows the approval or rejection of the generated refund request on the Mono side.
It runs every 5 minutes.
send_cancel_order_items
It enables the cancellation information created in Omnitron for an order to be sent to Mono. Before activating this flag, the settings under the second section above (Sales Channel Configuration)—Send Cancel Reason Id, Cancellation Reason Id, and Cancel Reason Mapping—must be configured appropriately.
Important Note:
It is crucial to differentiate between the cancellation reasons used in the Order Cancel flow and the reasons used in this flow. In other words, when performing the cancellation here, do not select a cancellation reason that corresponds to the IDs defined in the Cancellation Reason Id and Cancel Reason Mapping fields in the channel configuration. If such a reason is selected, the cancellation will not be sent to Mono.
It runs every 5 minutes.
10. Initial Mono Integration Setup Flow
Mono Marketplace Mapper Definitions
In order to ensure seamless data synchronization between Omnitron and the Mono marketplace, specific attribute mappings must be configured. These mappings define how product information in Omnitron is translated and transmitted to Mono according to its required schema. This section provides a step-by-step guide on how to access and configure these mappings using the Mapper.
Select the Mono sales channel under Sales Channels, then go to Sales Channel Settings > Marketplace Mapping > Mapper.
Mappings must be configured for the following Schemas:
RemoteId Schema
Title Schema
Seller Description Schema
Seller Basecode Schema
Seller Barcode Schema
When you click on a Schema within the Mapper, the following screen appears: Target Attribute(s) (Mono:101_Channel): This specifies which attribute value in Mono the data corresponds to. Mapping Method: Options include Standard, Fixed Value, and Custom.
Standard: Retrieves values currently in the brand’s Omnitron that are not yet matched with the marketplace.
Fixed Value: Sends a constant value to the marketplace regardless of the value in the brand’s Omnitron.
Custom: A configuration schema is prepared to send values according to the structure required by the marketplace.
Source Attribute (Omnitron): The attribute in the brand’s Omnitron that will be used for the mapping.
If Standard is selected, the attribute values must be mapped.
RemoteId Schema: In product submission requests, this corresponds to the SKU field expected by Mono. If no mapping is configured, the value is taken from the product’s SKU field in Omnitron by default.
Custom Mapping:
[
{
"key": "sku",
"type": "field",
"order": 0,
"prefix": "",
"is_object": false,
"default_value": ""
}
]"key": " ",
It is the field where the key to be used is specified.
"key": "sku",
"type": " ",
Field type.
"type": "field",
"order": 0,
Order
"order": 0,
"prefix": "",
It is used to add a prefix symbol such as _, ., or * before the key, if needed.
"prefix": "",
"is_object":,
If it is an object, it should be set to true.
"is_object": false,
"default_value": " "
It is the field where the default value is specified if the key has no value.
"default_value": ""
Seller Barcode Schema: In product submission requests, this corresponds to the Seller Barcode field expected by Mono within the required attributes.
Custom Mapping:
[
{
"key": "sku",
"type": "field",
"order": 0,
"prefix": "",
"is_object": false,
"default_value": ""
}
]Seller Basecode Schema: In product submission requests, this corresponds to the base_code field expected by Mono. If no mapping is configured, the value is taken from the product’s base_code field in Omnitron by default.
Custom Mapping:
[
{
"key": "base_code",
"type": "field",
"order": 0,
"prefix": "",
"is_object": false,
"default_value": ""
},
{
"key": "listing_code",
"type": "field",
"order": 1,
"concat": true,
"prefix": "_",
"is_object": false,
"default_value": ""
}
]Title Schema: In product submission requests, this corresponds to the name field expected by Mono. If no mapping is configured, the value is taken from the product’s name field in Omnitron by default.
Custom Mapping:
[
{
"type": "complex",
"order": 0,
"prefix": "",
"schema": {
"rules": [
{
"key": "name",
"type": "field",
"order": 0,
"concat": true,
"prefix": "",
"is_object": false,
"default_value": ""
},
{
"key": "integration_desen",
"type": "attribute",
"order": 1,
"concat": true,
"prefix": " ",
"is_object": false,
"default_value": ""
},
{
"key": "base_code",
"type": "field",
"order": 2,
"concat": true,
"prefix": " ",
"is_object": false,
"default_value": ""
},
{
"key": "listing_code",
"type": "attribute",
"order": 3,
"concat": true,
"prefix": "_",
"is_object": false,
"default_value": ""
}
]
},
"is_object": false
}
]Seller Description Schema: In product submission requests, this corresponds to the Seller Description field expected by Mono within the required attributes.
Custom Mapping:
[
{
"type": "complex",
"order": 0,
"prefix": "",
"schema": {
"rules": [
{
"key": "name",
"type": "field",
"order": 0,
"concat": true,
"prefix": "",
"is_object": false,
"default_value": ""
},
{
"key": "sku",
"type": "field",
"order": 1,
"concat": true,
"prefix": "<br>",
"is_object": false,
"default_value": ""
},
{
"key": "integration_icerik",
"type": "attribute",
"order": 2,
"concat": true,
"prefix": " <br>",
"is_object": false,
"default_value": ""
}
]
},
"is_object": false
}
]Last updated
Was this helpful?