Häufig gestellte Fragen
What distinguishes a REST API from a SOAP interface?
REST is an architectural style that works over the existing HTTP protocol, whereas SOAP is a standalone, strictly specified protocol that mandatorily transmits messages as XML. REST APIs mostly use the more compact and easier-to-read JSON format, are considered more resource-efficient and cache well, which makes them attractive for web, mobile and cloud applications. SOAP, by contrast, provides formal contracts (WSDL), transactional guarantees and, with WS-Security, a built-in security model, and therefore remains widespread in heavily regulated environments such as finance, public authorities or older corporate landscapes. In practice, many ERP systems operate both approaches in parallel, so the choice depends on the specific integration scenario and the counterpart systems involved.
Which HTTP methods and status codes does a REST API use?
A REST API addresses each business object – such as a customer or an order – via a unique URL and acts on it with the standard HTTP methods: GET reads data, POST creates new records, PUT and PATCH modify existing ones, and DELETE removes them. The server signals the result of each request via standardised status codes, for example 200 for a successful retrieval, 201 for a newly created record, 401 or 403 for missing authentication or authorisation, and 404 when a resource was not found. This clear and predictable mapping makes REST interfaces comparatively easy to understand and to document. Because REST works statelessly, each request must carry all the necessary information itself, without the server keeping session data between calls.
REST or GraphQL – which is the better fit for ERP integrations?
REST is well suited to classic, resource-oriented integrations in which clearly delimited business objects are read and written via stable endpoints, such as connecting an online shop, a shipping provider or an accounting tool. GraphQL, by contrast, is a query-oriented approach in which the calling client requests exactly the fields it needs across multiple objects in a single request, which can reduce over- and underfetching, especially for data-intensive frontends. Many modern ERP platforms offer both variants, so they complement rather than exclude each other. In practice, the exact design depends on the industry, company size and customizing depth of the specific ERP setup.
How is access to an ERP REST API secured?
Access is typically governed via API keys or tokens following the OAuth 2.0 standard, so that only authorised systems can retrieve or modify data. The Authorization Code Flow in particular is considered secure, often supplemented by the PKCE mechanism for applications that cannot store secrets securely; all communication should take place exclusively encrypted via TLS/HTTPS. Short-lived access tokens combined with refresh tokens have proven effective, as have narrowly defined permissions (scopes) that only allow the operations actually required. Credentials belong in protected storage and should not be placed in source code or public repositories; comprehensive logging of access also facilitates audits and troubleshooting.
What do rate limits and HTTP 429 mean for ERP APIs?
Cloud ERPs restrict the permitted number of requests per time window via so-called rate limits in order to protect the systems from overload and to guarantee fair access for all connecting applications. If an integration exceeds this limit, the API usually responds with status code 429 (Too Many Requests) and often with a Retry-After header indicating when a retry makes sense. The standard strategy is exponential backoff – progressively longer waiting times, ideally with a small random delay (jitter) – supplemented by queues that absorb load peaks. How many calls actually occur depends heavily on the setup; depending on transaction volume and polling frequency, the order of magnitude ranges from a few thousand to several hundred thousand calls per day.
When are webhooks more useful than repeatedly polling the REST API?
With polling, an application actively queries the REST API at fixed intervals and compares the responses to detect changes, whereas a webhook reverses the logic: when an event occurs – such as a new order or a stock change – the ERP system itself calls a registered URL of the target application. Webhooks deliver updates almost in real time and save resources because unnecessary empty queries are eliminated; polling, by contrast, produces many requests of which often only a fraction actually contains new data. Webhooks are therefore particularly suitable for time-critical, event-driven processes, while polling can be sufficient for less urgent or batch-oriented workflows. In practice, many systems combine both: webhooks report the event, and the REST API then delivers the complete detail data.