How to connect Kaspi.kz with 1C: orders, stock and duplicate customers

The reliable way to get Kaspi.kz orders into 1C is a small service in between, not a direct connection. The service pulls new orders from Kaspi and creates them in 1C, finds the buyer by phone so the same customer is not created twice, and sends stock and prices from 1C back to Kaspi.

Every exchange goes into a log. An order is not lost when something fails, and it is not created twice when a request is repeated. In a similar production project, where Kaspi was connected with an ERP and a CRM, new orders reached the CRM in about a minute and stock on Kaspi was updated in about 10 minutes.

What data moves between Kaspi and 1C

Data	From and to	When
New orders	from Kaspi to 1C	every minute
Customers	from Kaspi orders to 1C and the CRM	with each order
Stock	from 1C to Kaspi	on a schedule and on change
Prices	from 1C to Kaspi	on a schedule

Why not a module inside 1C

A 1C module that talks to Kaspi on its own looks simpler and cheaper. I would not build it that way, for three reasons:

• 1C is sometimes busy with period closing or an update, and the exchange silently stops.
• If a response gets lost, the retry creates a second order.
• When something fails, it is hard to tell what failed and when.

The service in between keeps its own state in PostgreSQL: which orders were already taken, the status of each exchange, the last error. If 1C is down, orders wait in a queue and go through when it is back.

Protection against retries is covered in detail in A repeated request must not create a second order.

How the order and stock exchange works

1. Every minute the service asks the Kaspi Shop API (documentation in Russian) for new orders. The merchant creates the API token in the seller account.
2. Order items are matched to 1C products by SKU. If there is no match, the service does not guess a product: the order goes to a manual review queue.
3. The customer is looked up by phone. An existing customer in 1C or the CRM gets the order, otherwise a new customer is created.
4. The order is created in 1C together with its Kaspi order number. Before creating it, the service checks that no order with that number exists yet.
5. Stock and prices from 1C go to Kaspi on a schedule and on change. The Kaspi storefront does not update instantly, and that delay matters for a product with one unit left.
6. A scheduled reconciliation compares orders and stock in both systems and reports differences.

Where a Kaspi and 1C integration usually breaks

• SKUs do not match. A product has one SKU in Kaspi and another in 1C. The mapping table has to exist before launch, or some orders end up in manual review.
• One customer, several records. Phone numbers are written differently: +7, 8, with spaces. Numbers are normalized before comparing.
• Several warehouses. Decide in advance which warehouses Kaspi should show stock from.
• Cancellations. An order cancelled on Kaspi must release its reservation in 1C. Otherwise the goods stay reserved for an order that no longer exists.
• Silent stops. An exchange can stop without a single error on screen. You need an alert when orders have not arrived for longer than usual.

I would not postpone the silent stop alert. Without it, you learn about the stop from a buyer who calls to ask where the order is.

Results in a real project

A retail company in Kazakhstan copied Kaspi orders by hand. Managers typed them into the ERP and the CRM, marketplace stock lagged behind the warehouse, and some orders had to be cancelled.

That project connected Kaspi with an ERP and a CRM. With 1C the scheme is the same, only the way the accounting system is called changes. After the service went live:

Metric	Result
New order in the CRM	in about 1 minute
Stock update on Kaspi	in about 10 minutes
Order processing time	80% lower
Operator errors and manual work	up to half as much
Cancellations caused by stale stock	halved

More in the project write-up: Kaspi, ERP and CRM in one flow.

How much a Kaspi and 1C integration costs

The price depends on how much data moves and in which direction. My packages as a reference:

Package	Includes	Price
Basic	one-way exchange, for example Kaspi orders into 1C, exchange log	$250
Standard	two-way exchange: orders into 1C, stock to Kaspi, retries on failure, duplicate merging	$600
Premium	everything in Standard, scheduled reconciliation, alert when the exchange stops	$1,200

The price is fixed as long as the scope matches the description. I give the timeline together with the price once I see the task. If orders also need to reach Bitrix24, see what drives the cost of a 1C and Bitrix24 integration.

What to prepare

• Access to the Kaspi merchant account.
• The name of your 1C configuration and a list of custom changes, if any.
• The warehouses whose stock should appear on Kaspi.
• SKU exports from Kaspi and from 1C to check the mapping.
• The person who will handle orders that did not go through automatically.

With this list you can send me the task. I will reply with a plan, the main risk and a fixed price.