Häufig gestellte Fragen
What is an API in simple terms?
An API (Application Programming Interface) is a clearly defined interface through which two software systems can exchange data and invoke functions automatically without knowing each other's internal workings. Instead of a person manually transferring data from system A to system B, the systems communicate directly via the API: one sends a request and the other returns a structured response. In the ERP context, an API is thus the technical foundation that allows a web shop, a CRM or a banking interface to work with the central system. Abstraction is key: the caller relies only on the documented interface, not on the underlying database or programming language.
What is the difference between REST and SOAP?
SOAP is a strict protocol that uses XML exclusively for requests and responses and offers standardised extensions, for example for message-level security (WS-Security), while REST is a more lightweight architectural style that typically builds on HTTP methods and the more compact JSON format. REST is considered the standard for new ERP and web integrations today because messages are smaller, caching is possible and integration is generally faster and easier to achieve. SOAP, on the other hand, is still found in older systems and in heavily regulated sectors such as banking or insurance, for example via classic SAP RFC or SOAP web services. In mixed landscapes both approaches exist in parallel, which is why integration platforms frequently mediate between the protocols.
What does API-first ERP mean?
An API-first ERP exposes every function via an API from the outset, and its own user interface accesses the same interfaces as external systems. This approach treats the API not as an afterthought but as a central building block of the software, which favours the most complete possible functional coverage and easier integration. In practice, platforms such as Odoo, Oracle NetSuite and Weclapp are frequently cited as examples, although the specific scope varies by edition and module and this mention does not constitute an endorsement. The advantage is that third-party systems can in principle reach all business objects and are not limited to a restricted subset of the user-interface functions.
What API standards exist in the ERP context?
The most widely used standard today is REST combined with JSON, which is employed in most modern ERP integrations. OData also plays an important role — an approach built on REST and standardised by OASIS that is used, for example, by Microsoft Dynamics 365 (Web API based on OData v4) and by SAP via the NetWeaver Gateway. GraphQL as a query-oriented approach is still comparatively rare in the ERP mid-market, while SOAP with XML persists as a legacy standard mainly in older or heavily regulated systems. In addition, webhooks are used to implement event-based push notifications instead of merely polling for data actively.
What are webhooks and do I need them?
Webhooks are a push mechanism and are occasionally referred to as a reverse API: when a specific event occurs in the ERP, such as a new order or a stock change, the system automatically calls a pre-configured external URL and hands over the relevant data. Unlike classic polling, where a program actively queries an API for changes at fixed intervals, webhooks deliver information in near real time and avoid unnecessary empty requests. They are useful when prompt reactions are required, for example for warehouse updates, notifications or synchronisation with a CRM. As a safeguard against outages, a hybrid approach is often recommended, with webhooks as the primary channel and supplementary polling picking up missed events afterwards.
How is access to an ERP API secured?
Access to an ERP API is governed by an authentication mechanism that checks who is calling the interface and which permissions apply. API keys are common for simple scenarios, while OAuth 2.0 and JSON Web Tokens (JWT) serve more demanding applications; current security recommendations favour short-lived, context-bound access tokens to make misuse harder. Transmission should always be encrypted via HTTPS, and credentials or tokens are ideally rotated regularly. In addition, so-called rate limits restrict the permitted number of calls per time window to protect the system's stability against overload or abuse.
What should you look for in an ERP system's API?
When evaluating an ERP system, the scope and quality of the interface are more meaningful than the mere existence of an API. Important criteria are open, versioned documentation, consistent authentication, clearly defined limits on call volumes (rate limits) and a separate test environment in which integrations can be tried out without risk. It is also decisive which business objects are reachable via the API at all, since not every function in the user interface is necessarily available through the interface. Because an API only provides regulated access and is not a finished integration project, it should additionally be clarified whether middleware or an integration platform (iPaaS) makes sense for more complex landscapes.