System integration via API -
a practical guide for the IT manager

Mid-sized and larger companies typically use more than a dozen separate SaaS and on-premise applications. CRM data does not make it into the ERP. Help desk tickets do not see the client's order history. Status changes in the logistics system do not update the IT dashboard. Each of those crossings is a place where data is lost, duplicated or goes stale, and an employee has to copy it by hand. This article explains how APIs, webhooks and middleware fix that, on a concrete example of ManageEngine ServiceDesk Plus connected to an ERP.

Why integrate systems: the real cost of data silos

A data silo is a state in which every system has its own truth. The ERP knows the client has an overdue payment, but the help desk does not, so the technician opens an urgent ticket and burns through their own time. The CRM stores the contact history, but the support team only sees the ticket ID. Logistics updates the delivery status, and IT only finds out by phone.

The cost of silos has four dimensions:

• Working time: manually moving data between systems eats a significant portion of an employee's day - time that could be spent on substantive work.
• Data quality: every manual copy carries the risk of an error (typo, stale data, missed field).
• Response time: a help desk without access to ERP/CRM context resolves tickets more slowly because it has to gather information from other departments.
• Compliance: inconsistent data between financial and operational systems is an audit and regulatory risk (e.g. KSeF, ISO 27001).

API integration eliminates these costs. Not by migrating to a single mega-system (which is rarely possible) but by creating a small channel through which data flows automatically and instantly.

REST API: basics you should not skip

REST (Representational State Transfer) is an architecture for communication between applications over HTTP. From an IT manager's perspective: it is the way one system "asks" another for data or issues it commands, through a defined, documented interface.

Anatomy of a REST request

Every REST request consists of four elements you need to understand when scoping an integration project:

• HTTP method: GET (fetch), POST (create), PUT/PATCH (update), DELETE (delete).
• Endpoint (URL): the resource address, e.g. https://sdp.company.pl/api/v3/requests/12345.
• Headers: request metadata, including the authentication token and the data format.
• Body: data sent with the request, most often in JSON or XML.

GET /api/v3/requests/12345 HTTP/1.1
Host: sdp.company.pl
Authorization: Bearer {API_KEY}
Content-Type: application/json

// Response:
{
  "request": {
    "id": "12345",
    "subject": "No access to ERP",
    "status": { "name": "Open" },
    "requester": { "name": "Anna Kowalska" },
    "priority": { "name": "High" }
  }
}

Data formats: JSON vs XML

In 2026, JSON is the standard for new APIs: lighter, human-readable, natively supported by JavaScript and most languages. XML persists in older ERP systems (especially Comarch ERP XL, SAP NetWeaver, SOAP web services) and anywhere schema validation (XSD) is required. If you are integrating a modern SaaS with a legacy ERP, you often have to handle both formats on both sides, which is the main reason middleware makes sense.

API authentication methods

Types of integration: API, webhooks, middleware, custom code

Not every integration looks the same. The choice of method depends on the direction of data flow, frequency, volume, and the availability of interfaces on both sides.

The key criterion: if both systems have a REST API with good documentation, start with direct integration or middleware. Custom code is only justified when the API is unavailable (legacy system without an interface), performance requirements exceed 500 req/s or business logic is very complex.

Case study: ManageEngine SDP + ERP (Comarch / Enova365)

Illustrative scenario: an IT hardware distributor with a classic problem - the support technician sees a ticket about no access to the warehouse module but does not know whether the client has an active service contract, has paid the last invoice or what their hardware configuration is. All that data sits in Comarch ERP XL. Result: the technician has to call sales or finance, which significantly extends the first response time. The integration removes that step - ERP context appears directly in the ticket. We describe an analogous scenario for manufacturing environments (Jira + ERP + MES) in detail in the article on integrating Jira with ERP and MES systems.

Here are the concrete steps of such a project:

Middleware tools: n8n, Zapier, Make

Middleware is the intermediate layer that connects systems without writing code from scratch. Instead of implementing authorization, JSON parsing, error handling and queueing manually, you configure it visually or with a minimal script.

When middleware, when custom code: decision matrix

n8n vs Zapier vs Make: short comparison

Our recommendation for companies in Poland: n8n self-hosted as the platform of first choice for integration. Installation on a VPS or on-premise server, full control of data, no per-workflow fees, the ability to write custom JavaScript code. Zapier makes sense only if you are integrating exclusively SaaS systems with ready-made connectors and you do not have the IT resources to host your own instance. We cover the specifics of integrating an ERP with a help desk system, from data mapping to error handling, in a separate guide: ERP integration with the help desk.

How to scope an integration project

Most "system integration" offers give a single number with no breakdown into components. That is a mistake on both sides: the client does not know what they are paying for, the vendor does not know what they have priced. Here is the pricing structure we use:

Cost components of an integration project

• Analysis and data mapping (10-20% of the budget): flow documentation, API audit, sessions with system owners. Critical: without this phase the project ends up being rewritten mid-delivery.
• Implementation of the integration layer (40-50%): middleware configuration or writing custom code, field mapping, format transformations.
• Error handling and resilience (15-20%): retry logic, dead letter queue, alerts, logging. Often skipped in cheap offers, and that is precisely what breaks integrations a month later.
• Tests and UAT (10-15%): unit tests, integration tests, load tests, UAT with users.
• Documentation and training (5-10%): data flow map, troubleshooting instructions, training for the admin.

Relative effort for typical integration projects

We prepare a precise quote individually after scope analysis - contact us to get an offer tailored to your systems. Validating an offer: if you get a quote without a phase breakdown, ask. Make sure the offer contains items for testing and error handling - without those, the integration often fails after go-live.

Common mistakes and how to avoid them

Based on integration projects we have delivered and fixed, we can point out the failure patterns that recur most often:

1. No data owner on either side

The integration synchronizes data, but who is the source of truth? If the client's status can be changed in both the CRM and the ERP, and the integration has no conflict resolution logic, after a week you have chaos. Always define the authoritative system for each field BEFORE implementation.

2. Happy path only in tests

The tests cover the ideal scenario: the API responds in 200 ms, data is complete, the systems are up. Production brings: a 30-second timeout, the ERP unavailable during backup hours (3:00-5:00), an empty NIP field on the ticket form. Test failure scenarios deliberately: turn off one of the systems in the test environment and check what happens to the data.

3. No error handling = silent data loss

A webhook sends an event, the receiver returns HTTP 500. Now what? If there is no retry mechanism, that event disappears. In middleware: always configure a dead letter queue or at least an alert on errors. In custom code: implement the Circuit Breaker pattern and idempotent operations.

4. API keys "forever" and shared

We audit clients' systems and regularly find: a single API key used by 4 different integrations, valid for 3 years, with admin permissions. If that key leaks, everything is compromised. One key = one integration. Minimum scope of permissions. Rotation every 90 days on the calendar.

5. Integration without monitoring = integration that has been down for months

An integration fails silently: the ERP returns a different JSON structure after an update, the webhook URL changed, the token expired. Nobody knows because nobody checks. Minimum: an email alert after N consecutive errors, a dashboard with the number of events processed per day, an alert when that number drops to zero.