Passo 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 to https://console.akinoncloud.com using your username and password.
From the menu, go to the App Store, select Passo as the sales channel, choose the relevant project, and proceed with the installation.
After the installation process, go to My Applications from the left menu, select the relevant application, and navigate to its application page. Once the necessary build and deployment steps are completed, the Passo Marketplace Dashboard application will become available in the left menu of Omnitron.
After the installation, the menu will appear as shown in the screenshot.
2. Sales Channel Definition
After the deployment of the application is completed in ACC, a sales channel will be automatically created in Omnitron. The fields within this sales channel need to be filled in.
You can access the sales channel via Omnitron > Settings > Sales Channels.
Channel Name
Sales Channel Name.
Passo
Automatically created.
Required (should not be changed)
Catalog Name
Catalog name created for Passo (may vary by brand).
Passo_Catalog
Automatically created.
Required (should not be changed)
Channel Type
Channel Type (all sales channel types are available as a dropdown in Omnitron).
Sales Channel
Automatically created.
Required (should not be changed)
Status
No processes will run unless the sales channel is activated.
Inactive
Default is inactive (activation required).
Required
Schema Type
Defines key/value schema used to generate the configurable form for this sales channel. You may add extra fields but MUST NOT modify existing keys. Keys: key, label, required, data_type (list, text, integer, bool, json).
{ "base_url": {"key":"base_url","label":"Base Url","required":true,"data_type":"text"}, ... }
Default minimum schema is pre-filled.
Required (additions allowed; existing fields fixed)
Base Url
API base URL for Passo.
https://fd041f331e5c46c7aca7a16abec6bbaa.lb.akinoncloud.com
Pre-filled as https://example.com/ and must be updated.
Required
Access Token
Fixed token used in requests to Passo (see authentication doc).
default
Pre-filled (obtained from Passo).
Required
Category IDs
Main category IDs from Passo to seed category tree (see Section 4).
f8aeb10e-... ffcc74a6-...
Blank by default; enter desired Passo root category IDs.
Required
Feature Flags
Enables/disables individual processes. All keys must exist with true/false even if disabled. (See Section 9 Feature Flags).
{"get_orders":false, "product":false, ... }
All flags default to false.
Required
Cargo Company Mapping
Maps Passo shipping slug to Omnitron shipping company; also sets default if brand does not manage shipping.
{"default":"3","yurtici":"2"}
Default key provided.
Required
Use Cargo Label
Generate a shipping label during order retrieval when brand does not manage shipping (send_shipping_info inactive). Label format is fixed PDF.
Inactive
Blank by default.
Optional
Use Neighborhood
Whether to use neighborhood data from address when creating orders.
Inactive
Default inactive; enable if ERP requires neighborhood info.
Optional
Order Number Format
Custom format when pulling orders. If blank defaults to {orderNumber}-{id}.
FD-{orderNumber}-{id}
Blank by default.
Optional
Default Reason ID
Fallback Omnitron refund reason ID if Passo refund reason not mapped.
5
Blank by default.
Required
Refund Reason Mapping
Maps Passo refund reason IDs to Omnitron IDs.
{"f3909f53-a535-40cc-8d50-de0cd047aedd":"7","f488f79f-503f-4787-a8ef-6a37b085b5e1":"5"}
Blank by default (then Default Reason ID is used).
Optional
Refund Start Date
Initial start date to begin pulling refunds (yyyy-MM-ddTHH:mm:ssZ).
2023-07-01T00:00:00Z
Blank by default.
Optional
Failed Integration
Records with errors are penalized before retry. See Section 3 Failed Integration Settings for defaults & examples.
Refer to Section 3
Pre-filled by default.
Required
Send Shipping Info
Whether shipping process is managed by brand (active) or Passo (inactive).
Inactive
Default inactive (Passo manages shipping).
Optional
Cancellation Reason ID
Omnitron cancellation reason ID used if Passo cancellation reason not mapped.
4
Blank by default.
Required
Cancel Reason Mapping
Maps Passo cancellation reason IDs to Omnitron IDs.
{"f3909f53-a535-40cc-8d50-de0cd047aedd":"1","f488f79f-503f-4787-a8ef-6a37b085b5e1":"3"}
Blank by default (then Cancellation Reason ID used).
Optional
Reject Item Reason
Return rejection reason used when rejecting refund items.
Damaged
Blank by default.
Optional
Attribute Set Strategy
Strategy deciding which attribute set products belong to.
CategoryNode
Pre-filled.
Required (should not be changed)
Use Channel ID In Address Mapping
Prefixes channel ID to address data when performing address mapping.
Inactive
Blank by default.
Optional
Buffer Stock
Value subtracted from available stock when sending to Passo.
3
Blank by default.
Optional
Waybill Option
If enabled and order status is Shipped/Delivered, sets waybill_number to invoice number or fallback default.
{"enabled":true,"default":"999"}
{"enabled":false,"default":""}
Optional
Send Cancel Reason ID
Omnitron cancellation reason ID used when sending (brand-originated) cancellation data to Passo. Must differ from Cancellation Reason ID and mapping values.
10
Blank by default.
Optional
Get Discount Amount
Use discount information when retrieving orders (inactive = ignore discounts).
Inactive
Inactive by default.
Optional
3. Failed Integration Setting
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 (Passo) 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 there is any error for a product during the sending process to Passo (e.g., missing stock, price data, incomplete mapping on the Omnitron side, or product not found, no response from Passo within the sent_to_remote time on the Passo side), the product will be penalized with the current failed integration setting. During the penalty period, no sending operations can be performed for that product. Since the product encountered an error, it will not be retried for a certain period. This ensures that the records with errors do not block the other records. Additionally, any BatchRequest entries awaiting remote response that exceed sent_to_remote.EXPIRATION_HOUR without a reply are marked failed, preventing unresponsive operations from blocking healthy ones.
4. Creation of Category Tree for Sales Channel and Creating Attributes
First, from Passo > Dashboard Visit the link to view the main categories, obtain the main category ID information to be used and add these IDs to the Category Ids field in the channel config.
The category tree is fetched based on the added Category Ids within the sales channel.
After the category tree is fetched into Omnitron, it can be viewed under the Category Management section when the relevant Passo is selected as the Sales Channel.
After this process completes successfully (which can be monitored via logs), the flow that fetches the 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 the category tree retrieval step is completed, the user needs to perform category mappings via the Mapper.
The Akinon Mapper function within Omnitron allows users to configure and manage the attribute values of the products they want to sell on marketplace sales channels according to the marketplace’s requirements. Additionally, it provides the capability to verify whether the attributes and their values are correct before the products go live for sale.
You can find detailed documentation about the Mapper and the necessary definitions to be made in the Mapper from Mapper tutorial.
You can find examples of custom mappings that you can create for Passo in Passo Marketplace Mapper Definitions.
6. Adding Products into the Category Tree
Products must be added to the relevant category tree on the Passo side. Each product should be assigned to only one category. Otherwise, errors will occur during the submission process.
7. Defining Screens
When the Passo marketplace application is installed on the relevant brand’s Omnitron, it appears as “Passo” in the left-hand menu.
7.1. Dashboard Screen
The dashboard data related to the Passo marketplace application is displayed on this screen.
TOTAL SKUS IN CATALOG The number of SKUs that are of type simple and active status in the related 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 that are in the catalog but not on sale in the marketplace. This section compares the sellable products in Omnitron with the products currently on sale in the marketplace. That is, products considered here have a price in Omnitron, stock greater than zero, a category, product image, and are present in the catalog.
NUMBER OF SKUS WITH PRICE DIFFERENCES CORRECTED The number of SKUs with price differences between Omnitron and the marketplace. If differences exist, a separate task has been run to correct the differences.
TOTAL STOCK QUANTITY IN CATALOG The total stock quantity of all products in the marketplace catalog.
TOTAL STOCK QUANTITY ON MARKETPLACE The total stock quantity of products currently on sale in the marketplace.
TOTAL STOCK DIFFERENCE Stock quantity of products that are in the catalog but not on sale in the marketplace.
TOTAL NUMBER OF SKUS WITH STOCK DIFFERENCES The number of SKUs with stock differences between Omnitron and the marketplace. If differences exist, a separate task has been run to correct the differences.
7.2. Monitoring Screen
This screen contains logs and reports.
7.2.1. Log Screen
The logs of the flows are displayed on this screen.
Category Node This flow fetches the entire category tree structure of the main categories entered in the channel settings into Omnitron.
Category Attribute and Values This flow fetches the category attributes entered in the channel settings into Omnitron.
Default Attributes This flow prepares predefined fields (such as remote_id, title, etc.) for the mapping process during product submission.
Product This flow sends products entered in Omnitron to the marketplace.
Product Delete This flow removes products deleted from the Omnitron catalog from sale on the marketplace.
Stock This flow sends the updated stock information of products with stock updates in Omnitron to the marketplace.
Price This flow sends the updated price information of products with price updates in Omnitron to the marketplace.
Order Create This flow fetches orders from the marketplace into Omnitron.
Order Update This flow updates orders on the marketplace when order status, invoice, or shipping tracking number is updated in Omnitron.
Order Cancel This flow updates the statuses of canceled orders on Omnitron when they are canceled on the marketplace.
Order Refund This flow updates the statuses of refunded orders on Omnitron when they are refunded on the marketplace.
Updated Orders This flow updates the statuses of orders on Omnitron when their statuses change on the marketplace.
Approve / Reject Refund Order This flow sends the approval or rejection information of refunds approved/rejected in Omnitron back to the marketplace.
Split Packages This flow transmits order split requests coming from Omnitron or another OMS system to the marketplace.
Compare Attributes This flow updates the statuses of category attributes in Omnitron when their statuses change on the marketplace.
Send Cancel Order Items This flow updates the statuses of canceled orders on the marketplace when they are canceled in Omnitron.
7.2.2 Report Screen
This screen provides reporting on products that have been added to the catalog in Omnitron but are not listed for sale on Passo. It highlights discrepancies between the price and stock information in Passo 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, in turn, helps deliver the best shopping experience to end customers.
Benefits of Alarms and Notifications
Real-Time Issue Detection: Alarms instantly identify integration errors, ensuring accurate data flow between systems.
Proactive Problem Resolution: Alarms enable timely intervention for integration issues, minimizing downtime and operational impact.
Enhanced Data Integrity: Alarms prevent data delays or interruptions, supporting consistent and accurate data processing.
Optimized Customer Experience: Rapid resolution of integration problems keeps order, stock, and product information always up-to-date, providing customers with a seamless shopping experience.
Enhanced Operational Efficiency: Alarms keep users informed about critical events, allowing them to focus on strategic tasks.
Data-Driven Decision Making: Alarms provide valuable insights to optimize integration processes.
Reduced Downtime: Early detection of issues minimizes system interruptions and prevents revenue loss.
Customizable Alerts: Akinon Marketplace Dashboard offers flexible alarm customization to fit 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, ensuring a reliable, efficient, and customer-centric shopping experience.
Alarm and Notification Setup Steps\
Step 1: Accessing Alarm and Notification Settings The Marketplace Dashboard is not a standalone product opened via a separate URL. To access it, first go to the Omnitron left menu, click on the Marketplace under the Sales Channels menu, and then select Marketplace Operations from the dropdown menu.
Step 2: Create a New Alarm and Notification Rule Click the + Create New Alarm button located at the top right corner of the “Alarms” screen.
In 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: Save 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 the Akinon Marketplace Dashboard, e-commerce integrations become more efficient. Real-time monitoring allows instant intervention to issues, ensuring data accuracy and delivering a flawless customer experience. Customizable alerts enable 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 threshold, the alarm is triggered.
7.4. Trigger Screen
This screen is used for triggering flows.
8. Steps to Follow for Errors
The steps to follow for common errors found in logs are as follows:
“Stock data not found” Indicates that the product’s stock data is missing. Stock data needs to be added for the related product.
“Price data not found” Indicates that the product’s price data is missing. Price data needs to be added for the related product.
“… attribute is required” Indicates missing mapping for the specified attribute. Mapping should be done as described in Section 5 (Marketplace Mapping).
“Unreported order of ERP can not be canceled” Indicates that the related order has not yet been sent to the ERP system. The order must be sent to ERP to proceed with the cancellation.
“Address is not valid. channel: 137 code: 137_Merkez model: Township city id: .., city name: …” Indicates that the Township in the address data of the order requires mapping.
Note on Product Triggering: Triggering a product from the dashboard only performs a create operation. If you want to trigger a product update, it must be done via CSV upload under “Update Bulk Product Version Date” in channel settings (top right), using the “Update via File Upload” option.
For triggering processes, refer to the Flow Trigger document.
Stopping the sending of faulty products or resending products that failed to send: Faulty products are retried for a certain period according to the rules defined in the Failed Integration settings within the channel configuration. For products whose retries have stopped according to this rule, manual triggering is required.
To remove products stuck in this state from the penalty queue: Go to Omnitron’s right menu, navigate to Settings > Sales Channels, select the relevant channel, and on the opened 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 and clear these products from the failed integration queue.
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:
Urgently fix errors related to mapping, catalog, stock, price, etc., and then trigger a CSV upload afterwards.
Properly configure the Failed Integration settings in the channel settings 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 updated attribute values, and if necessary, the Compare Attributes flow should also be executed.
Errors received after CSV upload:
sku cannot identify please check your csv file. Header value should be set this: sku This error occurs if the first row of the CSV file is not “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 related SKU does not exist in Omnitron.
The relevant record is processing in another queue, LocalBatchId: {local_batch_id} This error appears if the product being sent is triggered again while the sending process is still ongoing. Check the product logs and wait for the flow in "Waiting" status to complete. After completion, you can filter the logs by SKU to check the final status.
The relevant record is not in queue. The item may have been penalized or check product is saleable This error occurs if the product is inactive or not in the catalog.
Order Update (send_update_orders) flow and unresolved orders on MPD side:
If there is an ongoing or opened return process for the order, it will not be updated.
The tracking number value will only be sent if “Send Shipping Info” is marked active. For details, check the “Feature Flags” section.
The order status cannot be updated retroactively. Therefore, manual intervention in the flows is not recommended.
9. Feature Flags
The default frequencies for execution are as shown in the table below. These values can be modified by the Marketplace team.
Flag
Description
Frequency
get_orders
This feature flag enables pulling orders with the “Preparing” status from Passo to Omnitron by looking back 12 hours from the flow’s execution time.
Before activating this flag, the settings mentioned under the second 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 — must be properly configured.
It runs every 5 minutes.
get_cancel_orders
It pulls the canceled completed claims from Passo going 12 hours back from the flow's run time and processes the cancellation in Omnitron, ensuring that the cancellation plan count does not exceed 6. Before activating this flag, the Cancellation Reason Id and Cancel Reason Mapping settings in section 2 (Sales Channel Definition) must be properly configured.
It runs every 5 minutes.
get_refund_orders
Refund claims with open or waiting status on the Passo side are fetched, and the claim lines are retrieved to create a refund request in Omnitron. Before activating this flag, the Default Reason Id, Refund Reason Mapping, and Refund Start Date settings in the second section (Sales Channel Configuration) 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 Passo. Before activating this flag, the Send Shipping Info and Waybill Option settings in the second section (Sales Channel Configuration) 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
Detailed information can be found in the document at the link: Requirements and necessary configurations for the order splitting flow.
It operates via an outbound trigger sent externally by the OMS.
product
It ensures that products added to or updated in the catalog are sent to Passo along with their price and stock information. Before activating this flag, the Buffer Stock setting in section 2 (Sales Channel Configuration) above 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 Passo side.
It runs every 5 minutes.
price
It ensures that the prices of products that need to be updated are sent to Passo.
It runs every 5 minutes.
stock
It ensures that the stock quantities of products that need to be updated are sent to Passo. Before activating this flag, the Buffer Stock setting in section 2 (Sales Channel Configuration) above must be properly configured.
It runs every minute.
get_updated_orders
If the shipping processes are managed by Passo, this flag enables pulling orders with the status “Shipped” or “Delivered” from Passo going back 24 hours from the flow 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 section 2 (Sales Channel Definition) must be properly configured.
It runs every morning at 06:00.
send_refund_order_status
It enables the approval or rejection of the generated refund request on the Passo side.
It runs every 5 minutes.
send_cancel_order_items
It ensures that the cancellation information created in Omnitron for the order is sent to Passo. Before activating this flag, the settings in the 2nd section (Sales Channel Definition) — Send Cancel Reason Id, Cancellation Reason Id, and Cancel Reason Mapping — must be properly configured.
Important Note: It is crucial to distinguish between the cancellation reasons used in the Order Cancel flow and the cancellation reasons used in this flow. In other words, when performing the cancellation here, the cancellation reason corresponding to the IDs in Cancellation Reason Id and Cancel Reason Mapping in the channel config should not be selected. If selected, the cancellation will not be sent to Passo.
It runs every 5 minutes.
10. Initial Passo Setup Flow
Passo Marketplace Mapper Definitions
In order to ensure seamless data synchronization between Omnitron and the Passo marketplace, specific attribute mappings must be configured. These mappings define how product information in Omnitron is translated and transmitted to Passo 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 a Schema is clicked within the Mapper, the following screen appears:
Target Attribute(s) (Passo:101_Channel): Specifies which Passo attribute the mapped value will correspond to.
Mapping Method: One of the following methods can be used: Standard, Fixed Value, or Custom.
Standard: Brings values from the brand’s Omnitron that do not yet match with the marketplace.
Fixed Value: Sends a constant value to the marketplace, regardless of the value in the brand’s Omnitron.
Custom: Allows for sending values based on a configuration schema prepared according to the marketplace’s structure.
Source Attribute (Omnitron): The attribute in the brand’s Omnitron that will be used for mapping.
If Standard is selected, the attribute values must be mapped accordingly.
RemoteId Schema: Corresponds to the SKU field expected by Passo in product submission requests. If no mapping is defined, the value will be 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": " ",
This is the field where the key to be used is specified.
"key": "sku",
"type": " ",
Field Type.
"type": "field",
"order": 0,
Order
"order": 0,
"prefix": "",
If there is a symbol to be prefixed to the key (such as _, ., *), this field is used to add it.
"prefix": "",
"is_object":,
If the value is an object, this field must be set to true.
"is_object": false,
"default_value": " "
This is the field where the default value is specified in case the key has no value.
"default_value": ""
Seller Barcode Schema: Corresponds to the Seller Barcode field, which is one of the attributes expected by Passo in product submission requests.
Custom Mapping:
[
{
"key": "sku",
"type": "field",
"order": 0,
"prefix": "",
"is_object": false,
"default_value": ""
}
]Seller Basecode Schema: Corresponds to the base_code field expected by Passo in product submission requests. If no mapping is defined, the value will be 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: Corresponds to the name field expected by Passo in product submission requests. If no mapping is defined, the value will be 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: Corresponds to the Seller Description field, which is one of the attributes expected by Passo in product submission requests.
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?