The mistake of many projects is to choose technology “by eye”. Enquiries are transmitted with one webhook, the catalog is updated manually, stock levels are uploaded once a day, and order statuses are returned without error checking. As a result, data is late, events are lost, managers work manually, and the site displays outdated prices or statuses.
The integration method must be chosen according to the business scenario: what data is transferred, how quickly it should be updated, what will happen in the event of an error, and which system is considered the main source of data.
Why the integration method must be chosen before development
Integration is not just “connecting the API”. This is an agreement between systems: who sends data, who receives it, how often the exchange occurs, where errors are recorded, and what to do if one of the systems is temporarily unavailable.
If you do not describe this logic in advance, problems will appear after launch. The application may not get into CRM, the order may not go to 1C, the balance may be updated with a delay, and the client will see a status that does not correspond to reality.
Before choosing an exchange method, you need to determine:
- what data is transferred between systems;
- which system is the main source of data;
- how quickly the data should be updated;
- what to do if the transfer fails;
- Is it necessary to store exchange history;
- who is responsible for error checking;
- how to recover data after a failure.
What data is usually transferred between the site and systems
In most projects, the site exchanges several types of data: enquiries, orders, products, prices, stock levels, statuses, payments, delivery and customer data.
| Data | Examples | Where are they transferred? | What is important to consider |
|---|---|---|---|
| Enquiries | Form, name, phone, email, comment | CRM / Bitrix24 | Transfer speed and duplicate protection |
| Orders | Products, client, delivery, payment, amount | 1C / MoySklad / CRM | Reliability and error control |
| Stock levels | Warehouse, quantity, reserve | Website | Update frequency and risk of selling out-of-stock items |
| Prices | Retail, wholesale, promotional, personal | Website / customer portal | Price types and display rules |
| Statuses | Accepted, paid, collected, shipped, delivered | Website / client / CRM | Clear status map |
One exchange method is not always suitable for all data. The enquiry must reach CRM quickly. The catalog can be updated in batches. Stock levels require frequent synchronization. It is better to return statuses when a real event has occurred in the system.
REST API: controlled data transfer
REST API is a way in which one system talks to another and requests or sends data. For example, a site can send an order to CRM, request payment status, get a list of products, or update customer data.
This approach is convenient when you need to manage the exchange logic: select fields, wait for a response, handle an error, check the result and not send the same order twice.
REST API is good for:
- transfer of orders and enquiries;
- integration with CRM, payment or delivery;
- receiving status from an external system;
- customer portal work;
- flexible scripts with response checking.
The downside is that the API needs to be designed. It is not enough to know the method address: it is important to understand the required fields, response statuses, timeouts, retries, authorization and logs.
Webhooks: reaction to an event
Webhook is a way to notify another system about an event. It is not the site that constantly asks “what has changed?”, but the system itself sends a signal when an action has occurred: a form has been submitted, a payment has been made, the status of a transaction has changed, or a task has been created for the manager.
Webhook is suitable when quick response is important:
- new enquiry form;
- order payment;
- change of transaction status;
- delivery notification;
- event in CRM or customer portal.
The main risk of webhook is event loss. If the receiving system is temporarily unavailable, the request may not be processed. Therefore, we need logs, retries, signature verification, protection against duplicates, and clear error handling rules.
Scheduled exchange: regular synchronization
Scheduled exchange is a regular synchronization of data. For example, a site receives stock levels every 15 minutes, updates prices once an hour, or loads a large catalog of products at night.
This approach is often used for 1C, MoySklad, warehouse systems and large catalogs. It is suitable where data can be updated in batches and not every change requires an immediate response.
The downside of the schedule is the delay. If stock levels are updated once an hour, the site may show data that is already out of date. The frequency of exchange should depend on the turnover of goods, the risk of errors and the criticality of the data.
REST API, webhooks and scheduling: comparison
One method is not better than the other in all cases. REST API, webhooks and scheduled exchange solve different problems and are often used together in complex projects.
| Method | When suitable | Pros | Restrictions |
|---|---|---|---|
| REST API | Need to request or send data in a controlled manner | Flexibility, control, clear request logic | Need error and retry handling |
| Webhooks | Need a reaction to an event | Fast event transmission, fewer unnecessary requests | An event can be lost without logs and retry mechanics |
| Scheduled exchange | Data can be updated regularly and in batches | Convenient for catalogues, prices, stock levels and large volumes | Data is updated with a delay |
How to choose an integration method for a task
You need to choose not a technology, but a scenario. Fast transfer to CRM is important for the form. Relevance is important for stock levels. For a large catalog, stable batch processing is important. Clear feedback to the customer is important for order status.
| Task | Better to use | Why |
|---|---|---|
| Sending an enquiry to CRM | Webhook or REST API | The event should quickly reach the manager |
| Order transfer | REST API + error handling | Reliability and control of the result are important |
| Update stock levels | Schedule or API | The choice depends on the turnover of goods |
| Bulk catalog upload | Scheduled exchange | Large volumes are more convenient to update in batches |
| Order status update | Webhook or REST API | The client must see the current status |
| Payment integration | Webhook + verification via API | We need to receive the event and confirm its authenticity |
For critical data, you cannot rely on just one weak mechanism. For example, a payment notification can be received via a webhook and then additionally checked for payment status via the API.
Combined circuit for complex projects
In real projects, one approach is rarely enough. An online store can receive a catalog and stock levels on a schedule, send orders via REST API, receive payment statuses via a webhook, and verify data using nightly synchronization.
Example circuit:
- product catalog is updated according to schedule from 1C or MoySklad;
- stock levels are updated more often than descriptions and images;
- the order from the website is transferred to CRM or 1C via API;
- payment is confirmed by a webhook event;
- delivery status is returned to the site after the change;
- A reconciliation is run at night to find discrepancies.
This architecture is more complex than “connecting one API,” but it is more reliable: different types of data receive different rules for exchange and error handling.
Typical integration errors
Most problems arise not because of the lack of an API, but because of the weak exchange architecture.
| Error | Consequence | How to prevent |
|---|---|---|
| No logs | The error is difficult to find | Log requests, responses, statuses and exchange times |
| No retries | Event lost due to temporary failure | Configure retry mechanics and error queue |
| No single data source | Website, CRM and accounting system show different values | Assign a master system for each data type |
| Everything is done one way | Integration is becoming fragile | Combine REST API, webhooks and task scheduling |
| Statuses not described | The client and manager see different order states | Agree on the status map before development |
What to prepare before website integration
Before development, you need to collect not only access credentials, but also a description of the business logic: a list of systems, a list of data to be transferred, the main source for each type of data, frequency of updating products, prices and stock levels, rules for transferring orders, a status map, log requirements, incident procedures and post-launch verification scenarios.
The better the logic is described, the easier it is to choose the right exchange method. Sometimes webhooks are enough. Sometimes you need a REST API. Sometimes a scheduled exchange is optimal. Complex projects usually require a combination circuit.
Output
REST API, webhooks and scheduled exchange are different tools for different tasks. The REST API gives control, webhooks help you quickly respond to events, and the schedule is convenient for regularly synchronizing large amounts of data.
The choice depends on the business scenario. Enquiries, orders, stock levels, prices, statuses, payment and delivery require different exchange logic. If you choose a method at random, the integration will be unstable or create manual work where it should have been removed.
DevAstro designs API integrations for websites, online stores and B2B portals: it connects websites with CRM, 1C, MoySklad, Bitrix24, payment, delivery, analytics and internal business systems. Read more: API integrations.
FAQ
When should a synchronous REST API be used?
Use it when a user or system needs an immediate command or lookup result. Set strict timeouts and idempotency, and move long or failure-prone processing to an asynchronous queue.
When are webhooks a better choice?
Webhooks fit event notifications such as a paid order or changed status. They still require signature verification, deduplication, retry handling and protection against late or out-of-order delivery.
When is scheduled synchronization safer?
Scheduled sync is useful for large data sets, regular reconciliation and updates that do not require an instant response. It needs checkpoints, partial restart and freshness monitoring.
Can one integration combine all three methods?
Yes. A common design uses REST for commands, webhooks for events and scheduled jobs for reconciliation. The combination should be based on latency and recovery needs rather than technology preference.
How are duplicate events handled?
Store a stable event or command ID and make processing idempotent. Replaying the same payload must not create another order, payment or customer record.
What makes an integration supportable?
Use correlation IDs, structured logs, queues, retry limits, dead-letter handling, dashboards and named owners. Test outages, duplicates and malformed data before production launch.
