A sound integration project starts not with choosing an API but with a document only the business can write: which systems are involved, which one is authoritative for each entity — product, price, stock, customer, order, payment — what should happen when something fails, and who owns the data exchange after launch. Developers also need test access, anonymised sample data and acceptance criteria. With such a brief the estimate rests on facts rather than the contractor's assumptions.
Contents
Why integrations get more expensive as they go
An integration connects systems with different owners, different rules and different rates of change. Technically it is often a well-understood task: 1C, Kaspi Shop, CRMs and messengers all have documented ways to exchange data. Scope grows for another reason — questions the business has to answer surface in the middle of development.
- It turns out prices are edited both in 1C and in the marketplace dashboard, and nobody knows which one wins.
- Products in the accounting system and on the marketplace are not matched, and matching has to be done by hand.
- Exceptions — returns, partial shipments, orders cancelled after payment — are not described, so the developer invents the rules.
- Access to a 1C test database or the seller dashboard takes weeks because nobody is responsible for granting it.
- After launch it is unclear who handles exchange errors: the contractor, your 1C developer or a sales manager.
A map of systems and data flows
Start with a list of systems: the 1C configuration name and version and who maintains it (an in-house developer or an outside firm), Kaspi Shop, the payment provider, the CRM, messengers, the website. Then describe the flows — every movement of data between two systems.
- 01Website and Kaspi
- 02Orders and payments
- 03CRM
- 041C
Stock
- From → to
- 1C → website, Kaspi
- Trigger
- Stock change or schedule
- Acceptable delay
- How long the business can tolerate selling out-of-stock items
- Volume on a normal day and at peak
- Number of SKUs
Prices
- From → to
- 1C → website, Kaspi
- Trigger
- Price list change
- Acceptable delay
- Your call
- Volume on a normal day and at peak
- Number of SKUs and how often prices change
Orders
- From → to
- Website, Kaspi → CRM, 1C
- Trigger
- New order
- Acceptable delay
- Your call
- Volume on a normal day and at peak
- Orders per day, on promotion days
Payments
- From → to
- Payment provider → order
- Trigger
- Provider event
- Acceptable delay
- Your call
- Volume on a normal day and at peak
- Payments per day
Notifications
- From → to
- CRM → customer's messenger
- Trigger
- Order status change
- Acceptable delay
- Your call
- Volume on a normal day and at peak
- Messages per day
The “Acceptable delay” and “Volume” columns are deliberately blank: this is your data, and it is what determines the exchange method. Stock that must update “almost immediately” and settlements “once a day” are different technical solutions with different costs.
Source of truth and conflict rules
Assign one authoritative system to each entity. This is not a technical question: only the business knows where prices are edited and who owns the customer record.
Product and attributes
- Authoritative system
- For example, 1C
- Who makes changes
- Merchandiser
- What to do on mismatch
- Storefronts are overwritten from the authoritative system
Price
- Authoritative system
- For example, 1C
- Who makes changes
- Sales department
- What to do on mismatch
- Decide whether a separate marketplace price is allowed
Stock
- Authoritative system
- Warehouse accounting system
- Who makes changes
- Warehouse
- What to do on mismatch
- Storefronts update from accounting; manual edits there are forbidden or logged
Customer
- Authoritative system
- For example, the CRM
- Who makes changes
- Sales managers
- What to do on mismatch
- A duplicate rule: by phone, email or both
Order and status
- Authoritative system
- Define per stage
- Who makes changes
- Manager, warehouse, accounting
- What to do on mismatch
- Who may cancel an order after payment
Payment
- Authoritative system
- Payment provider
- Who makes changes
- Nobody, manually
- What to do on mismatch
- Payment status is confirmed by querying the provider, not only by a notification
What you can know about the platforms in advance
Some constraints are set by the platforms themselves. Knowing them before the brief helps you decide who on your side grants access and who is responsible for changes.
1C:Enterprise
- What the official documentation says
- The platform can automatically generate a REST interface over OData 3.0 for the main configuration objects once it is published on a web server. Custom HTTP services are defined in the configuration by a 1C developer, who writes the response logic in the built-in language
- What to prepare
- Your 1C developer's contact, a copy of the database for testing, a decision on publishing the interface
Kaspi Shop
- What the official documentation says
- The seller generates the API token in the web dashboard: Settings → API token. The API is used to add products and process orders
- What to prepare
- Who in the company owns the token and how it gets replaced
CRM (Bitrix24 as an example)
- What the official documentation says
- Connections via an inbound webhook, a local app or a marketplace app; request rate limits apply
- What to prepare
- User permissions for the integration, the list of pipelines and fields
WhatsApp Business Platform
- What the official documentation says
- Cloud API requires a business portfolio and a business phone number; outside the customer service window only message templates, which generally need approval, can be sent
- What to prepare
- The list of notifications and their texts as templates
Telegram bot
- What the official documentation says
- Updates arrive in one of two mutually exclusive ways — getUpdates or a webhook; a webhook can carry a secret that Telegram sends in the
X-Telegram-Bot-Api-Secret-Tokenheader - What to prepare
- Who creates the bot and keeps its token
Payment provider
- What the official documentation says
- Depends on the provider: ask for documentation, a test environment and a description of payment notifications
- What to prepare
- The provider contract, test credentials, the list of refund scenarios
Failures, exceptions and life after launch
An integration will inevitably meet an unavailable system, a duplicate message and data that does not reconcile. Decide in advance what should happen in each case — otherwise the developer will decide, and not necessarily in the way that suits your business.
- 1C is down for an update or nightly maintenance: do orders queue up, or does a manager get notified?
- An order arrives twice: the system must recognise the repeat and not create a second document.
- A marketplace product is not matched in accounting: does the order stop, or is it created with a flag for manual review?
- Payment went through but the order was cancelled: who starts the refund, and where is it visible?
- Partial shipment or product substitution: how is it reflected in the marketplace order and in the CRM?
- Who receives exchange error notifications, where — and who is obliged to act on them?
- How often are the systems' control figures reconciled: order count, totals, stock?
- Who maintains the integration after launch, and what happens when one of the platforms changes its API?
If the integration sends customers' phone numbers and names to a CRM or messengers, take personal data requirements into account — for example, where the data must be stored. How this affects system choice is covered in the article on corporate LMS; the details should be agreed with a lawyer.
A brief template and the order of work
The brief does not need to be long. It is enough for it to answer the following sections:
- Goal: which manual work or errors the integration should remove, and how you will know it works.
- Systems: list, versions, owners, contacts of the people responsible on your side.
- Flows: a “from — to — trigger — acceptable delay — volume” table.
- Source of truth and conflict rules for each entity.
- Exceptions and failures: what to do in each case from the list above.
- Access and test environments: what exists, who grants it, how long it takes.
- Sample data: anonymised orders, products and customers in their real format.
- Acceptance criteria: scenarios that must pass on test data before the live flow is switched on.
- Operations: who gets notifications, who maintains it, how often reconciliation runs.
Brief
Fill in the sections above as far as you can; gaps are information too.
Working session
The developer, your 1C developer and the process owner walk through the flows and exceptions.
Data contract
Fields, formats, identifiers and statuses are written down before the first line of code.
Pilot one flow
Start with one flow — orders, for example — on test data, with a log and notifications.
Switch-over and reconciliation
The live flow goes on after the trial run, with daily reconciliation in the first weeks.
Scope comes from the number of flows, the complexity of matching reference data, the number of exceptions, the state of the 1C configuration and the availability of test environments. The cost is determined after a brief and an agreed scope.
