What is the difference between an API, an interface and an integration?

An interface defines how pieces of software communicate with each other. An API is an interface through which programs retrieve data or execute functions. An integration connects systems so that they form a working business process. MDN Web Docs

The difference is crucial for your project: an existing API makes data exchange possible. But it does not yet mean that your orders automatically end up in your inventory management system, prices are assigned correctly or shipping information reaches the customer.

schukai takes on all three tasks: we develop APIs, program interfaces and implement complete integrations – from planning through roll-out to maintenance and operation.

The terms at a glance

Every API is an interface. An integration uses interfaces to complete a specific task across systems. MDN Web Docs

What is an interface?

An interface describes where and according to which rules two programs or software components exchange information. It defines, for example, which data format is expected, which details are required and how the handover takes place.

This does not have to be a web API. An agreed CSV import, an XML export or exchange via a messaging system can also serve as an interface. schukai.com

An example: every night, your inventory management system exports a file with item numbers, prices and stock levels. The online shop reads in this file. This creates a file-based connection – even without direct API calls between the shop and the inventory management system.

Whether this approach is sufficient depends on the task. It may be fine for a product catalogue updated daily. For checking availability during an order, a nightly sync may be too late.

What matters is not how modern an interface sounds, but whether it provides the required data on time and reliably.

What is an API?

API stands for Application Programming Interface. Through defined calls, an application can access specific data or functions of another piece of software.

An API might, for example, offer these tasks: search for an item, query a stock level, create a customer or return the status of an order. A person would have to use a user interface to do this. Other software uses the calls provided instead.

An API is not automatically public or accessible via the internet. It can also be used within an application or exclusively within the company network. MDN Web Docs

What needs to be defined for an API?

For the connection, it must be clear which functions are available, which data a call needs and which responses come back. Access rights, error messages and the rules for changes to the API are just as important. For HTTP APIs, many of these details can be documented in a structured way, for example with OpenAPI. OpenAPI Initiative Publications

The software being called may already apply extensive business rules: for instance, it checks an order before saving it. An API is therefore not simply uncontrolled access to the database. OWASP Cheat Sheet Series

Even so, the statement “Our system has an API” does not yet answer the decisive question: Does this API cover exactly the functions, data and workflows that you need?

What does integration mean? An example from order processing

An integration combines the technical possibilities with your operational rules. It determines which data goes where, what happens to it there and how the result is reported back. Microsoft Learn

Suppose you want orders from a B2B online shop to be transferred automatically to your inventory management system. The desired workflow could look like this:

The order is transferred. The shop passes on the order lines, delivery address and agreed terms. The connection translates this information into the format of the inventory management system and uses its interface to create the order.

The data is assigned correctly. The shop customer must belong to the right customer account. Item variants must be identified unambiguously. If the customer orders two cartons of twelve units each, this must not become an order for two single units.

The result is reported back. The shop receives the order number and the processing status. Shipping status and tracking number can follow later. If an item mapping is missing, the affected order should be ready for clarification instead of lying unnoticed.

In this example, the API provides certain functions. The connection calls them and transfers the data. The integration ensures that the individual steps work together according to the agreed rules.

Why “transferred successfully” does not always mean “done”

The success of a single API call does not automatically mean that the entire business process has been completed. A system can accept a request for later processing. The HTTP status 202 Accepted explicitly denotes processing that has been accepted but not yet completed.

Likewise, 200 OK confirms the success of the request in question – not, as a rule, of all subsequent work steps. RFC Editor

Taking over orders therefore needs a concrete success criterion: the order has been created in the inventory management system, its number is known and its status has been returned to the shop. A mere acknowledgement of receipt is not enough.

What an integration has to deliver in operation

Define which data comes from which system

Not every system should be allowed to change the same information. For your project, for example, the inventory management system could determine prices, while product descriptions are maintained in the shop.

This responsibility is defined for each data area. Changes in both directions also need clear rules: which change takes precedence? How are conflicts detected? When may an existing value be overwritten? schukai.com

Not just transferring data, but understanding it correctly

Fields with the same name can have different meanings. “Stock” can refer to the quantity physically present or to the quantity still available for sale after reservations.

That is why we clarify not just field names but the meaning of the data. This includes identifiers, variants, units of measure, pricing bases and status values. Only this mapping turns transferred numbers and text into information that the target system can work with correctly.

Choose the right level of timeliness

Some information is needed immediately. Other information can be transferred at fixed intervals. An API alone guarantees neither real time nor continuous synchronisation.

We define what triggers the transfer and how quickly the data must be available in the target system. Options include regular polling or event-driven transfers. We also take into account data volumes and the technical limits of the systems involved. Microsoft Learn

With event-driven connections, it must also be clarified whether messages can arrive late, more than once or out of order. An older stock update must not reset a newer state unnoticed. Stripe Docs

Handle interruptions without duplicating cases

If a connection drops, it is not always clear whether the target system has already created the order. An uncontrolled retry could create it a second time.

Unique case identifiers, checks of the processing status and – where the systems involved support it – idempotent calls help prevent this. “Idempotent” here means that repeating the same operation has no additional business effect.

A server that is temporarily unreachable must also be handled differently from an unknown item number. In the event of a connection problem, a later retry can make sense. With faulty master data, the cause must be fixed first. Amazon Web Services, Inc.

Make errors visible where they are dealt with

A technical log helps the development team. Order processing, by contrast, needs understandable information: which case is affected? What is missing? Who needs to act? What has already been done?

We therefore plan error handling as part of the workflow. This includes traceable statuses, suitable notifications and a controlled way of continuing to process corrected cases. For critical data flows, an additional reconciliation can uncover missing or differing entries. schukai.com

Protect access and keep changes manageable

A connection should only be able to access the data and functions it actually needs. Encrypted transfer, protected credentials, input validation and appropriate logging are therefore part of the technical implementation. Confidential information must not end up in error messages or logs without control. OWASP Cheat Sheet Series

For later operation, we also clarify who tracks changes to external systems, tests adjustments and introduces new versions. An integration must not only work on the day of acceptance but must also be supported and developed further. schukai.com

Can systems without a suitable API also be connected?

Yes, provided other suitable means of access are available. Depending on the software, existing import and export functions, file-based procedures, extension modules or approved database access may be options. For your own applications, or ones that can be extended accordingly, we can develop a missing API. schukai.com

We assess which solution makes sense on the existing system. A reliably automatable export can do the job better than an API retrofitted at great effort.

The limit is reached where the required data or functions are not accessible. Then it must first be clarified whether the vendor allows an extension or whether the workflow can be implemented differently. We point out such dependencies before implementation.

Is a ready-made connector enough?

A connector is a software component that handles the connection to a specific system. If an existing connector covers your workflow, the connection does not have to be developed from scratch. Microsoft Learn

The specific requirements need to be checked, however. Does it only support importing customers, or changes too? Does it handle standard prices only, or customer-specific terms as well? Does it process cancellations? How does it handle errors?

We use the existing options and develop whatever your workflow is missing. That can be a small extension, a dedicated connection or the coordination of several systems.

What does schukai take on?

API development, interface programming and complete system integration: you can commission us for individual tasks or for the entire implementation.

Develop and extend APIs

We develop programming interfaces for your applications and back ends. This includes the available functions, data structures, access rules, validation and documentation. We can extend existing APIs if your software and the available access rights allow it.

Connect existing systems

We program connections, set up data transfers and implement the required mappings and transformations. This applies, for example, to shops, inventory management, customer management, accounting, shipping services and custom business applications. We develop the specific connection on the basis of the available interfaces and your requirements.

Implement complete workflows

We take care of clarifying the business requirements and develop the logic between the systems: triggers, processing steps, responses, retries and error handling. If there is no interface in which your employees can check or approve cases, we develop that too. schukai.com

Take on roll-out, maintenance and operation

We test the agreed workflows, including relevant error cases, support the roll-out and document the solution. You can also hand maintenance, monitoring and operation over to us. We define responsibilities and the scope of services to suit your project.

Our offer is not limited to Shopcloud or Workspace. We also connect existing applications from other vendors. You do not need to introduce a schukai product first.

Which systems should work together in your company?

Describe which programs you use, which data is transferred by hand today and what should happen automatically in future.

Together with you, we clarify whether existing interfaces are sufficient, whether an API needs to be added or whether several systems should be connected into one end-to-end workflow. We then take care of the right implementation.

You describe the project. We take care of the connection.

You do not need a finished specification.