Torgsoft Integrations: Marketplaces, CRM and Online Stores

1. How to organize the exchange and who is responsible for what

Adapter — a separate program or site module that converts Torgsoft files into requests to the external service API and prepares files of new orders for Torgsoft. The platform API provides allowed operations with its products, orders, or contacts. Feed — a catalog file that the service downloads via a link or accepts through its import mechanism.

The connection consists of two parts. The integrator configures export and import in Torgsoft. The developer creates or installs a compatible module on the site, CRM, or marketplace side. Activating the option provides Torgsoft capabilities within its documentation; the third-party exchange service performs data conversion and works with the API of the selected platform.

One person can perform several roles. In the technical specification for each area, the executor and the result by which the work is verified are still defined.

Directions of data transfer

Three ways to connect

1. Standard integration. The owner activates the option or TOM module, the integrator configures it according to the instructions. The list of operations is defined by the connection documentation.
2. Third-party adapter. The integrator prepares the Torgsoft file exchange, the developer works with the API or platform feed and generates order files.
3. Connection via a site or CRM. Torgsoft exchanges data with one system that has connectors to other channels. The developer determines the order routing, the source of stock balances, and the reservation rules for all links.

For each channel, one routing for incoming orders into Torgsoft is defined. For example, marketplace orders are transmitted by a direct adapter or via CRM. Simultaneous import through both routes requires a common mechanism for eliminating duplicates.

2. What to prepare in Torgsoft and how to read its files

The basis of the adapter is the format for synchronizing an online store with Torgsoft. The settings are described in the option instructions. Prior to development, the integrator passes the actual product file, export settings, and the database version number to the developer.

2.1. Preparing the synchronization object

1. Activate «Synchronization with an online store» and open Warehouse → Synchronization with an online store.
2. Create an object with the channel name. Select the accounting centers for export and the center from which orders are placed.
3. Determine the price source for the invoice: Torgsoft or the online store. To save the purchase price on the platform, check «For invoice products, take prices from».
4. Agree on reservation, handling of missing quantities, and the account or cash register for payments.
5. Set fields, file names, encoding, client transfer, and the photo delivery method.
6. Configure the exchange address, manually transfer test products, and download one order.
7. After verification, enable the schedule and notifications for the responsible employee.

On the «Clients» tab, search by phone, creation of new clients, and updating of their data are checked. The developer transmits the phone in the agreed international format. Searching by phone does not replace the order key and does not protect against re-creating the document.

2.2. File delivery: FTP with TLS or web server directory

The «Web-server» type works with files in a specified directory. It does not create a universal REST API for Torgsoft. SFTP is a different protocol; its support in Make, n8n, or a marketplace does not mean support in the selected Torgsoft delivery method.

Directories for the product feed, orders, contacts, and certificates are separated by access rights. Behind the public URL of the advertising system, only the allowed product file and images are placed.

2.3. Products, prices, stock balances, and photos

TSGoods.trs — is the typical name for a CSV with a ; separator. The fields, their names, order, header, and filename are customizable. An alternative format is YML, an XML catalog with a corresponding tag structure.

The CSV parser is configured according to the actual export: separator, headers, encoding, quotes, and numbers. Special characters are checked on a test file. In UTF-8 mode, Torgsoft generates a product CSV with a BOM — a service encoding mark at the beginning of the file; the adapter must process it.

Torgsoft's YML is not a ready-made feed for every service. The developer checks the root element, mandatory tags, characteristics, languages, and the recipient's ID. For example, Hotline uses its own XML structure, and marketplaces require category codes and characteristic values.

2.4. New order format

Torgsoft accepts text files .sal. From DB version 493, XML and JSON in UTF-8 are also supported. For SAL, the synchronization object's encoding is used; in UTF-8 mode, a BOM is required. The filename is composed of ASCII characters: Latin letters, numbers, and safe separators.

API data is converted into the Torgsoft schema: the buyer goes into Client, parameters into Options, items into Goods. Mandatory fields: Client.Name, Options.OrderNumber, Options.SaleType, and GoodID, Price, Count for each product.

JSON example with conditional data for a pre-order:

{
  "Client": {
    "Name": "Тестовий покупець",
    "MPhone": "+380670000000",
    "EMail": "buyer@example.com"
  },
  "Options": {
    "OrderNumber": "SHOP-A-100042",
    "SaleType": "1",
    "OrderDate": "2026-10-05 12:00:00",
    "CurrencyInternationalCode": "UAH",
    "Comment": "Тестове замовлення зовнішнього каналу"
  },
  "Goods": [
    { "GoodID": "201", "Price": "1290.00", "Count": "1" },
    { "GoodID": "202", "Price": "350.00", "Count": "2" }
  ]
}

Before loading, the integrator substitutes real GoodIDs of the test database and checks documents in the program. The developer generates a stable OrderNumber from the channel code, store, and external ID. The numbers of different orders and stores must not match.

Additional fields transmit address, delivery, reserve date, currency code, trade type, and accounting center. Availability depends on the DB version. WarehouseID is taken from Torgsoft; the marketplace warehouse code requires mapping. The purpose of WarehouseID in the general parameters and the product row is described in the exchange format.

2.5. SaleType: what documents the import creates

For SaleType 2–5, the documentation assumes the availability of all required quantity in the accounting center. If the product is missing, the sale may result in a negative balance. Before automatic document creation, quantities and rules of action for shortages are checked.

The comment «paid» does not process the payment. SaleType does not refund funds in the payment service. The developer and integrator agree on the platform event, document type, receipt account, and further actions of the employee.

2.6. Clients, wholesale prices, and certificates

According to the settings, Torgsoft exports TSClients.trs: full name, contacts, address, client card, discount, amount for its calculation, and accumulated bonuses. The developer determines the matching key and sends only the necessary fields to the recipient. Purchase history is not included in this file.

The «Wholesale pricing policy» option adds an XML with quantity thresholds and prices. For certificates, a CSV TSGiftCertificate.trs is provided. The recipient must implement the appropriate pricing or loyalty rules.

Used bonuses and certificates are transferred in the order via BonusPay and GiftCertificate. The integrator activates the required options and settings; before payment, the developer checks the current data according to the agreed process. The team verifies the final deduction in Torgsoft and the rules for purchase cancellation.

The export of bonuses and certificates is a snapshot at the time of creation. Using loyalty in multiple channels requires an agreed checking and deduction process. The file itself does not block the reuse of a certificate in another store.

2.7. Schedule, POST messages, and import confirmation

Products and orders can have separate tasks. The integrator selects the synchronization type and the executor: Torgsoft or the automatic task server. To be run by the program, the application must be open on the specified computer under the specified user. For background operation, the service, its version, permissions, and file access are checked.

The interval is set according to the help recommendations: no more than once every 10 minutes, taking other objects into account. The developer separately configures the frequency of API requests. Frequent polling of the platform does not speed up the import of the file into Torgsoft outside the schedule.

«Send POST request after synchronization» notifies the site about the completion of the exchange. The developer provides the URL, name, and parameter value; the integrator sets them in the program. For the request, the timeout, allowed User-Agent, and redirects are set. A timeout of 0 means indefinite waiting.

This message is not a stream of all sales or return events. After it, the adapter reads the prepared files. The external platform's webhooks are received by the adapter's own HTTP handler.

In the FTP scenario, the order file is downloaded locally and deleted from the FTP, then processed by the program, and after a successful import, it is deleted locally. The disappearance of the file from FTP does not confirm the creation of the document. A faulty file in the local directory can prevent further import; the integrator checks the log and documents.

3. Standard integrations and TOM capabilities

For these scenarios, Torgsoft functions or specialized options are used. The owner gets access in the external service, the integrator configures the mode. Support covers documented connection operations.

Documentation: Torgsoft integrations, program help, bank statements.

Ready-made Torgsoft Online Market modules

Torgsoft Online Market, TOM — an online store platform that works together with Torgsoft. Access, payments, feeds, and external resources are configured in the TOM panel. Its integrations relate to store data and do not create an API for all Torgsoft documents.

4. Online store platforms

CMS requires a module that matches site items with Torgsoft products, updates agreed fields, and transmits new orders. The owner provides access to the store and defines the inventory. The integrator prepares file exchange. The developer installs a compatible connector or creates an adapter to the platform API.

Before launch, define who creates product cards and manages descriptions. For an already filled site, only prices and stock can be transferred. If the adapter will create cards, it additionally needs categories, characteristics, variants, photos, and publication rules.

5. Marketplaces and classifieds

Prom.ua, Rozetka, and Satu.kz are discussed among standard options. This table describes the operation of a third-party adapter for platforms. The owner first registers a seller cabinet and access to necessary operations. The developer checks application permissions, category requirements, price, and quantity format, and the integrator prepares Torgsoft exchange.

Transmitting only the article, name, and price is sufficient to update some already created offers. To publish a new card, all mandatory platform attributes are needed. Data missing from the product file is stored in the adapter's mapping table or directories.

Mandatory marketplace mappings

• Product: Torgsoft GoodID → seller SKU → offer ID and its variant. For a bundle, composition and quantity recalculation rules are saved.
• Warehouse: accounting center → platform warehouse/location/storefront. Sales from marketplace warehouses are separated from own ones.
• Order: channel + seller cabinet + external ID → OrderNumber. The number is used consistently on all subsequent retrievals.
• Price: currency, taxes, promotional and actual purchase price. The platform commission does not automatically reduce the sum of items in the order.
• Status: which statuses allow import, reserve, payment, shipment, and manual cancellation. Statuses in different systems have their own meanings.

6. Product catalogs and advertising channels

These services receive product data to display offers. The order is placed in the designated sales channel, from where it is transmitted to Torgsoft. The owner prepares the business cabinet and site; the developer creates a feed or uses a ready-made store module; the marketer checks diagnostics and advertising.

The feed is published entirely: the developer checks the structure, number of items, and link availability, and then replaces the live version. An empty or incomplete file is blocked until the cause is clarified, so the external service does not unpublish current offers.

7. CRM and omnichannel sales

A CRM can aggregate orders from sites and marketplaces. Such a scheme requires a separate bridge between the CRM and Torgsoft. The presence of channel connectors in the CRM does not configure this bridge automatically.

The owner determines the source of stock balances and the reservation procedure. The developer collects orders, saves the source channel and ID, maps products, and creates the Torgsoft file. The integrator checks the resulting documents. Until the order is imported and affects the accounting stock, the adapter or CRM accounts for it in the agreed channel reserve.

How to distribute statuses

The developer maintains a mapping table: CRM status, import condition, SaleType, and manager action. For instance, a confirmed unpaid order can create an invoice without shipment. After actual payment of an already created invoice, the manager or a separate supported mechanism registers the payment. Re-importing the same order as a new invoice is excluded.

Cancellations and returns after import go into the reconciliation queue. The responsible employee modifies Torgsoft documents and confirms the completion of the operation. Automation of this stage is included only with a specific supported method of working with the document.

8. Mailings, telephony, and messengers

For SMS, Viber, emails, and telephony, first check standard Torgsoft settings from Section 3. For marketing platforms, the developer uses the allowed contacts export. The owner defines the purpose of transmission, the legal basis for sending messages, and the opt-out procedure.

The messenger webhook is received by the adapter. It verifies the event, saves it in the log, and responds to the platform. The Torgsoft file is created after verifying the order. This allows reprocessing the event without re-creating the document.

Binotel is used within the standard telephony scenario. To link a call with a CRM or a separate bot, a custom route and access rights to call data are defined. The buyer's phone number is not an identifier of their order.

9. Payments and delivery

9.1. Online payment and bank statement

TOM modules for LiqPay, Portmone, and monobank, as well as standard bank statements, are given in Section 3. For another site, the payment provider is connected on the site's side. The developer confirms the payment result, and the integrator agrees on its display in Torgsoft.

If a new order is received already with confirmed full payment, SaleType=2 can be agreed for it. For automatic accounting shipment, a separately agreed scenario SaleType=3 is required. If the invoice is already created in Torgsoft, a later payment is not a reason to download this order again as a new one.

Partial payments, cash on delivery, commissions, refunds, and amount discrepancies are processed by separate rules. The integrator specifies the receipt account, the manager reconciles the sale amount with the payment, the accountant — with the provider's payout. Retained commission and the amount received in the bank do not automatically change the price of purchased products.

9.2. Transmitting delivery data

The sales document and the transport waybill have different purposes. For delivery, the owner sets up a carrier account. The developer passes address data and external identifiers; the integrator determines where the TTN (waybill) is created and how the employee sees it in Torgsoft.

Nova Poshta fields that need to be mapped

In NewPostDeliveryOptions, RecepientType, full name, and phone are transmitted. For branch delivery, WarehouseRef or city and branch number are used. If WarehouseRef is passed, city and branch number are not needed for this search. For address delivery, the respective street, building, and apartment fields are filled.

If DeclarationNumber is filled, other fields of this block are ignored: the existing TTN is used. Its download is intended for import with an outgoing waybill — SaleType 3 or 4 — or after generating an invoice from a pre-order. The integrator verifies this process in their scenario.

10. Analytics and file automation

A defined set of data is transmitted to an analytical service: catalog, stock balances, clients, or exported report. The developer and analyst agree on field names, snapshot date, currency, and period. The product file is not used as a source of full sales history.

For regular report export, the integrator defines its generation method in Torgsoft separately. The developer does not plan automatic access to any database data simply based on the presence of file synchronization.

11. How to ensure reliability, security, and maintenance

11.1. Store mappings separately from product names

The developer creates a permanent mapping storage. Product name can change, and barcodes are not always unique for all records. Before primary mapping, the integrator checks the directory; unapproved matches are not merged automatically.

11.2. Define a single rule for stock balances

The integrator shows the developer what exactly the exported quantity contains: physical stock or availability already reduced by accounted reserves. The developer documents the calculation for each channel.

For a bundle of several products, the developer calculates the number of sets based on the bundle composition. For fractional products, checks the unit of measure and allowed platform precision. Zero quantity means an agreed action with availability, and card deletion is performed only by a separate rule.

11.3. Verify orders before publishing the file

1. Check source, account, external ID, and allowed status.
2. Find GoodID for each item. For an unknown SKU, send the entire order to the correction queue.
3. Check quantity, units, currency, prices, and discounts. Calculate the total and compare it with platform data.
4. Agree on display of delivery, surcharges, and gifts. If a separate service is used, its GoodID and accounting behavior are checked by the integrator.
5. Check buyer, address, and carrier parameters required for the chosen scenario.
6. Select SaleType according to the agreed table and generate the schema file supported by the DB version.

A file with a missing item or unknown product is not published as a partial order without a separately agreed process. Error data is saved for correction; after it, the same external ID is used.

11.4. Protect import from duplicates

The developer creates a unique key «channel + account + external ID» in the log. A repeated event updates the state of this record. Before a new publication, the adapter checks whether the file was already sent and whether the document in Torgsoft is confirmed.

Practical log states: received → verified → file prepared → published → import confirmed. Errors and records requiring reconciliation are kept separately. Confirmation of the last state is determined by the real available mechanism of the specific integration or by the verification of a responsible employee.

Acceptance by the FTP server, HTTP 200, and file deletion are not considered a universal document confirmation. After a failure on the transmission boundary, the adapter stops republishing this order until reconciliation. The OrderNumber value itself is not a documented guarantee against all repeat imports.

11.5. Publish only completed files

The incoming product file is read after its generation is completed and structure is verified. POST message, schedule, or gateway are used according to the configured route. The adapter controls file integrity and rejects incomplete records.

The adapter's result is first written to a service directory, checked, and then published as a completed file. For orders, the temporary file has an extension that the importer does not process. Renaming is performed within the file system or a verified server mechanism; the atomicity of this step is verified by the administrator.

The working product feed is kept until the successful verification of the next version. The number of products, proportion of zero balances, mandatory fields, and file size are compared. Anomaly thresholds are agreed with the owner so that a planned assortment delisting is not blocked without explanation.

11.6. Separate errors and retries

• Authorization: stop the respective route, notify administrator, renew access per platform rules.
• API limit or temporary unavailability: save the task and retry with controlled delay, observing Retry-After if provided.
• Incorrect data: send record for correction; do not republish an unchanged erroneous file.
• Partial batch result: read responses for each product and retry only allowed unexecuted operations.
• Undefined import result: reconcile document before retrying.

Monitoring shows the last successful update, age of stock balances, number and age of untransmitted orders, SKU errors, and overdue confirmations. The owner assigns an employee for each notification type. An API request with a successful HTTP code is additionally checked for business errors in the response body.

11.7. Protect access and personal data

• Enable SSL/TLS for Torgsoft FTP and check actual encryption. External HTTP interfaces of the adapter run over HTTPS.
• Store keys and passwords in secure configurations. Do not add them to public feed URLs, repositories, messages, and logs.
• Issue minimum permissions. Use separate access for production environments and trials.
• Verify webhook signature and authorization validity per provider instructions. Save event to reliable storage before confirming its acceptance.
• Separate the public directory from client, order, bonus, and certificate files. Limit retention period and employee access.
• Mask unnecessary contact and payment data in logs. Agree on passing contacts for advertising with consent and opt-out rules.

11.8. Test manual and background execution separately

The administrator and integrator check the current Torgsoft version, automatic task server, and libraries supplied for this connection. Incompatible SSL libraries are not replaced with random DLLs from third-party sites.

A control order is run manually and via the actual service. Check the service user, rights, directories, language and regional settings, network access, and the result after a restart. Successful manual import does not confirm background task operation.

After changing the program version, file schema, pricing, site modules, or API, key tests are repeated. The developer maintains versions of the adapter and exchange contract; the owner assigns a person responsible for updates.

12. Testing and acceptance plan for integration

The free 30 days of the option can be used to test the exchange with the selected service. First, the owner sets up access and approves the scenario; after that, the integrator activates the option, and the developer launches the prepared adapter. Application approval by the external platform, its tariffs, and development are considered separately.

What must be ready before the first launch

Sequence of work

1. Checking access. The developer performs allowed reading of catalog and orders, checks authorization and required operations.
2. Catalog test. The integrator exports control products; the developer checks new and existing cards, variants, prices, and zero quantity.
3. Order test. The developer transmits a file; the integrator verifies buyer, each GoodID, quantity, price, currency, and created documents.
4. Payments and delivery. The manager and integrator check agreed payment types, reserve, shipment, and TTN.
5. Failures and retries. The team tests repeat events, loss of access, incomplete file, unknown SKU, and service restart.
6. Limited launch. The owner admits the agreed assortment and channel; the team observes several full cycles and reconciles the result.
7. Acceptance. The owner receives the manual, test log, monitoring access, and maintenance procedure.

Control tests

For each test, the team records in the log the actual result, external ID, OrderNumber, and Torgsoft document. A JSON example and checking its syntax do not replace import in the installed version of the program.

Prior to handover, the owner receives a list of automated operations, manual exceptions, update intervals, and responsible persons. Platform tariffs, necessary options, adapter support term, update and disaster recovery procedures are recorded separately.