System and API integration for business

API integration of business systems

API integration lets two or more systems exchange data automatically and trigger related processes. This can be sending orders from a website to CRM, syncing stock with ERP, receiving delivery statuses, or exchanging data between internal platforms.

Before development we define which data is transferred, in which direction, how often, and which system is the source of truth for each data type.

Integrating a company’s information systems

When a business uses several independent systems, employees often move data by hand, work with duplicates, and spend time reconciling information. Integration joins these systems into one process without replacing the entire infrastructure.

We design the system connection with business rules, API limits, security, load, and further architecture evolution in mind.

Which systems can be integrated

CRM integration with a website

Website inquiries can automatically create leads or deals in CRM and pass the source, contact data, selected service, and extra fields. Reverse sync can be used for statuses, personal data, or a client account.

See also: CRM development.

CRM and ERP integration

Connecting CRM and ERP helps split system responsibilities and remove repeated data entry. For example, CRM handles communication and sales, while ERP handles accounting, warehouse, documents, and order fulfillment.

Before implementation it is necessary to define the master system for clients, nomenclature, orders, payments, and statuses.

See also: ERP development.

Online store integration

An online store can be connected to CRM, ERP, warehouse, payments, delivery, mailings, analytics, and other external services. The integration layer must handle errors and not block the critical purchase scenario when an external API is temporarily unavailable.

See also: e-commerce development.

Mobile app integration

A mobile app usually talks to the backend through an API. If some data lives in external systems, the backend should act as a controlled integration layer and not send third-party secret keys to the mobile client.

See also: mobile app development.

SaaS platform integration

A SaaS product can provide its own API and at the same time connect to external services. For such solutions it is important to define API versioning, rate limits, webhooks, tenant isolation, and a way to manage client credentials in advance.

See also: SaaS platform development.

REST API development for integration

If one of the systems does not provide a suitable exchange interface, a custom REST API can be built for safe access to the needed data and operations.

The API should have clear endpoints, input validation, authorization, error handling, logging, and versioning if long-term support of several clients or integrations is expected.

Client exchange interfaces belong to web application development.

Webhooks and event-driven integration

For processes where changes must be sent right after an event, webhooks or other event-driven mechanisms are used. For example, a payment status change can automatically change the order status and trigger further actions.

A webhook endpoint must verify request authenticity, handle event redelivery, and be resilient to duplicates.

If the external system does not support webhooks, sync can run periodically. Request frequency should consider API limits, data freshness, and load on both sides. Do not run heavy sync from browser/client components: such processes should run on the server or in background jobs.

Webhook security

• verify the external service signature/secret if the mechanism is available
• check the timestamp if it is part of the signature protocol
• do not trust the payload without server-side validation
• protect the endpoint from processing the same event twice
• return correct HTTP status codes

Which system is the source of truth

For clients, products, orders, prices, stock, and statuses a master system must be defined. Without this, two systems can change the same field at once and create conflicting data.

The source-of-truth decision is fixed in the technical integration scheme before development starts.

For each entity explicitly define the exchange direction: source → target or two-way sync. Two-way exchange is harder and needs conflict-resolution rules. Example: stock may come only from ERP, while new orders come only from the online store.

Data mapping and identifiers

Create field mapping between systems: identifiers, data types, required fields, dictionaries, enum values, date formats, currencies, and units. Keep transformation logic in the integration/service layer, not hardcoded in the UI.

Synced entities need a stable matching mechanism: externalId, internalId, or a separate mapping table. Matching only by name, phone, or email can create duplicates.

Integration error handling

Integration must distinguish temporary and permanent errors: timeout, rate limit, 5xx, invalid data, missing access rights, and other scenarios.

The user interface must not hide critical errors. Internal processes should have a sync status and a clear retry mechanism.

For temporary errors use controlled retries with a limited number of requests and delay between them. Infinite retry is forbidden. Creating payments, orders, inquiries, or documents should be idempotent where possible.

Queues and background jobs

Heavy or unstable external integrations can be moved to a queue so the user’s HTTP request is not held until the third-party operation finishes.

A queue worker should store job status, attempt count, the last error, and have a dead-letter/failed mechanism if the project needs it. For large volumes consider external API rate limits: batching, queue, caching, or another load-reduction mechanism.

If you need end-to-end process orchestration: business process automation.

External API authorization

The supported auth method is defined by the external service: API key, OAuth 2.0, bearer token, signed request, and other mechanisms. Store secrets only on the server. Do not put credentials in the client bundle or use public env vars for secret keys.

If the integration needs OAuth, access and refresh tokens must be stored on the server. Token refresh, revoke handling, and a correct state when the user withdraws access are required.

Integration logging

Integration processes need a technical log: request time, system, operation, internal correlation ID, HTTP status, and error. Do not write passwords, access tokens, full bank data, or other secrets into an open log.

For a chain of several systems it is useful to pass a correlation/request ID so one identifier can restore the operation path. Critical integrations should have error and availability monitoring.

System integration stages

API integration cost

Integration cost depends on the number of systems, the quality and limits of their APIs, the number of entities, exchange direction, the need for webhooks, background jobs, queues, data migration, and reliability requirements.

After a technical analysis we fix the integration scope and critical scenarios and can split implementation into stages. For complex links it is rational to first validate one key process, then expand the integration.

Integration or data migration

Integration keeps regular exchange between systems, while migration moves data from one system to another once or several times. A project can use both: first migrate historical data, then keep ongoing sync.

Integration with existing and legacy systems

If a legacy system has no modern REST API, first study available exchange methods: SOAP, files, database access, a message queue, or export. Direct access to an external database should be used only with a justified need and controlled rights.

CSV/XML/JSON exchange can be acceptable if there is no API and data updates in batches. If the external service works through SOAP, a separate adapter can hide SOAP specifics behind the application’s internal interface.

Personal data and the test contour

If personal data is transferred between systems, the integration should pass only the fields that are actually needed. Do not copy sensitive data into every system without a business need.

Use sandbox/test environments of external services where possible. If there is no sandbox, production testing should run on limited test entities with protection against real payments, mailings, or actions.

Frequently asked questions about system and API integration