API Integration: ERP, CRM and Online Store

What is the difference between an API and a webhook?

An API is an agreed way for one system to request or send information to another. An online store can request stock availability, send an order to an ERP system or check the status of a shipment. The system that needs the data initiates the communication.

A webhook works in the opposite direction. When an event occurs, the system sends a notification to a predefined address. For example, a payment provider can notify your software of a successful payment, after which it can update the order status and trigger the next step.

Which processes should you connect first?

Do not start by trying to connect everything. Choose a process that occurs frequently, slows down your team or creates costly errors. This is usually order processing, customer enquiries, stock availability or payments.

Online Store, Warehouse and ERP

When a new order is placed, the store sends the products, quantities, customer details and payment method to the ERP system. The ERP returns the stock availability and status, while the store receives updated quantities whenever warehouse stock changes. This reduces the risk of selling an item that is already out of stock.

Before development begins, clarify which system is the source of truth for the price, stock availability, product and customer. If both the store and the ERP can change the same value without a defined rule, the integration will only move the conflict faster.

Website, CRM and Sales Team

A website enquiry form can create a lead in the CRM with its source, service, phone number and message. The system can then create a task for a sales representative, send a confirmation or route an urgent enquiry to a specific person.

The most common problem here is not the lack of an API, but an unclear definition of a lead. You need to know when a new contact is created, what happens with a repeat enquiry and who receives the task. Otherwise, you will end up with duplicate customers and unevenly distributed enquiries. When your CRM process is specific, custom CRM system allows these rules to be built directly into the system.

Payments, Invoicing and Notifications

A successful payment can change the order status to “paid”, send the data to the ERP and trigger invoice creation. It is important that the invoice is not created again if the payment provider sends the same notification more than once.

Website, CRM and Telephony

When there is an incoming call, the phone system can send the number to the CRM so the customer record opens automatically. After the call, the outcome, a task or a note is recorded. This is useful when sales and support teams handle a high volume of incoming enquiries.

What does integration look like in a real business system?

With LiftexPro, ERP for elevator companies, different operations are part of one common process: scheduling inspections, managing buildings, coordinating technicians and automated invoicing. This type of system shows why integration is not just about transferring fields between two programs. You need to know what happens after each status and who has permission to change it.

For field teams, for example, it is not enough to record the visit. The result must reach the right asset, create or update a task, feed into invoicing and remain visible in the customer history. These dependencies are what determine the architecture and the tests.

What are the options for connecting systems?

The choice depends on the number of systems, the documentation, the scenarios and the cost of an error. A no-code tool is convenient for simple data exchanges. A ready-made connector makes sense when it supports your exact process. A custom integration is more suitable when you have an ERP, several channels or specific rules.

With a ready-made connector, a low price does not mean the work is finished. Check the fields, tax rules, duplicate records, rounding, declined payments and refunds. With a custom integration, the budget is driven mainly by the number of scenarios and exceptions, not just by the number of systems.

If the main issue is the store and its operations, connections to payment providers, couriers and internal systems should be planned as early as the online store development. If the store is already running, the integration is built around its actual API capabilities and limitations.

How does a reliable API integration work?

1. 01
   Documenting the process

   Document what happens today from start to finish. Who enters the order, where is stock checked, when is the invoice issued and who is notified of a problem? This reveals the manual actions and the points where information gets lost.

2. 02
   Checking the systems and documentation

   Check whether each system has an API or webhook, how access is authenticated, whether there is a test environment and what the limitations are. Ask the external provider for documentation, sample requests and the rules for interface changes.

3. 03
   Defining the data and responsibilities

   Map the fields: order number, SKU, quantity, price, VAT, customer, address and status. Determine which system can change each value and what happens when there is a discrepancy.

4. 04
   Building a small initial scenario

   Start with one flow, such as a new order to the ERP or a new lead to the CRM. Do not include all notifications, reports and exceptions at once. The small initial scenario shows whether the logic is correct.

5. 05
   Testing edge cases

   Test a declined payment, unavailable stock, an incorrect phone number, a returned order, a deleted product, a broken connection and a repeated webhook. These cases show whether the integration is ready for real work, not just whether it works in a demo.

6. 06
   Monitoring and handing over to the team

   Provide a request log, an error notification and a way to retry processing. The team must be able to see which order is blocked, why it is blocked and how to fix it without modifying the database.

What goes wrong most often?

A request is processed twice

A webhook may be sent again if the recipient does not confirm it in time. Every event should have a unique identifier, and the system should check whether it has already been processed. This is especially important for payments, invoices and shipment dispatches.

One system is unavailable

If the ERP does not respond, the order should not disappear. It should be added to a queue, retried in a controlled manner, and a person should be notified if the problem persists.

The data has a different structure

One system may use separate fields for first name and last name, while another may use a single name field. SKU, units of measure, VAT rates, time zones and addresses also often differ. These transformations should be part of the integration rather than being left to employees.

Access is too broad

API keys and passwords should not be stored in code or sent by email. Use an encrypted connection, separate access for test and production environments, minimum permissions and a key rotation procedure. For personal data, also review retention periods and employee access.

How can you tell whether the integration is successful?

Set your criteria before development begins. All new orders should reach the ERP, every lead should have an owner, every error should be visible to an employee, and no payment should create two invoices.

Do not measure only whether the data has “arrived”. Check whether the process is completed correctly, whether the team can respond to a problem, and whether reprocessing can take place without manually editing the database. For an example of what connected objects, roles and operations can look like, see the demo ERP system.

When should you choose a ready-made tool and when custom development?

Make or Zapier are practical for sending a notification, creating a task or transferring a simple form. They are a good way to test an idea and automate a small process. However, with larger volumes, you need to calculate operation limits, monthly dependency and how recovery will work when an error occurs.

A ready-made plugin is suitable when the store and the accounting or courier system support exactly the required scenario. If you have specific business pricing, multiple warehouses, complex returns or different order rules, the plugin may prove too restrictive.

A custom integration makes sense when an error means a lost sale, incorrect stock levels or a problematic invoice. It allows you to use your own logic, control the data and recover more effectively when a system is unavailable. Most importantly, there should be documentation and someone responsible for the process after launch.