Sellers on Kaspi.kz have access to the Shop API: it lets you retrieve orders and manage products and statuses programmatically instead of working by hand in the merchant cabinet. The seller generates the authorization token themselves in the cabinet (Settings → API token), after which requests carry the X-Auth-Token header. In practice, integration covers three jobs: orders land in your CRM or accounting system automatically, stock and prices stay in sync between the website, 1C and the Shop, and statuses update without manual entry.
Contents
Why integrate when there's a cabinet
The merchant cabinet works fine while order volume is low. Beyond that comes a familiar picture, and each of its operations costs staff time and produces errors. Integration turns manual work into background work:
Cabinet only
- A manager copies orders into a spreadsheet or CRM by hand
- Shop stock drifts from the real warehouse
- Prices update a day late
With integration
- An order appears — a deal is created
- Goods ship — stock is deducted
- A price changes in accounting — the storefront updates
The business keeps using the cabinet; it just stops duplicating data into it.
What the Shop API gives you
The official Kaspi Shop seller API follows the JSON API specification and is designed for working with orders, products and related data. The basics most integrations are built on:
- Retrieving the order list and order details — the basis for automatically creating deals in a CRM or documents in an accounting system.
- Working with order statuses — updating progress without manual actions in the cabinet.
- Uploading and updating products — prices, availability and attributes from your source system.
Three typical scenarios
In our experience, requests from businesses in Kazakhstan come down to three connections:
- 01Kaspi Shop
- 02API · X-Auth-Token
- 03CRM
- 041C / warehouse
Orders → CRM
- How it works
- Shop enquiries land in the same pipeline as website and messenger leads
- What it gives you
- The manager works in one window, and channel analytics become honest
Warehouse ↔ Shop ↔ website
- How it works
- A single source of truth for stock and prices (usually 1C or an accounting system), with the other channels syncing automatically
- What it gives you
- No more selling what you don't have
Documents and accounting
- How it works
- The required documents are generated from the order
- What it gives you
- The data reaches bookkeeping without re-entry
Pitfalls
Honestly about what makes these projects harder:
- Platform limits: the integration must handle errors and retries properly instead of falling over on the first non-response.
- Data discrepancies: you need an operations log and clear rules about whose version wins in a conflict — otherwise investigations eat the savings.
- Platform changes: an API has a life of its own, so integration is planned with maintenance in mind, not as one-off work.
- Access: only registered Shop sellers can connect to the API — the token and permissions are verified before development starts.
How we do it
The order of work is standard for integration projects:
Audit
Which systems, where the source of truth is, what the volumes are and which processes depend on them.
Exchange design
Which data, in which direction, how often, and what happens on errors.
Development and testing
Development and mandatory testing on test data.
Switching the live flow
Only after testing on test data.
The parts we never cut:
- Operation logging — you can see what succeeded and what failed
- Retries on failures
- Notifications to a responsible person when something needs human attention
Without them an integration breaks quietly — and you notice a week later from mismatched numbers.
We estimate your case after the brief: the scope depends on the number of systems, the quality of your product data and the required sync frequency.
