REST API
Also: RESTful API · REST-Schnittstelle · RESTful Webservice
A REST API is a programming interface that exchanges data over the web protocol HTTP: every resource such as a product, order or customer has its own address (URL) and is read or modified with standard commands. In an ERP, the REST API connects the system to shop, marketplace, payment and shipping.
A REST API (Representational State Transfer) is a widely used architectural style for programming interfaces in which systems exchange data over the ordinary web protocol HTTP. The core idea: every piece of information is a “resource” – a product, an order, a customer – and each resource is reachable through its own unique address (URL). Another system accesses that address and usually receives the data back in the lightweight JSON format, or modifies it. REST is therefore not a product or a piece of software but a set of conventions that providers follow so their interfaces are simple, predictable and broadly usable.
In the ERP world, the REST API is today the standard way a merchandise management or ERP system talks to the rest of the system landscape: to the online shop, to marketplaces, to payment and shipping providers, and to accounting. Because REST builds on the same mechanisms as the web itself, it can be addressed with almost any programming language and any tool. That makes REST APIs the most widely used form of integration for modern cloud ERP systems.
At a glance
- REST = architectural style for web interfaces over the HTTP protocol
- Every resource (product, order, customer) has its own URL
- Standard commands: GET (read), POST (create), PUT/PATCH (change), DELETE (remove)
- Stateless: every request contains all the information needed
- Data mostly as JSON – today the de facto standard for ERP integrations
How a REST API works
REST follows the classic request-response principle: a client (such as the ERP or a shop) sends a request to a URL, the server processes it and returns a response. What is special about REST is how these requests are structured. The URL names the desired resource, and an HTTP verb determines what should happen to it. So a GET on the address /orders means “give me all orders”, a GET on /orders/4711 means “give me order 4711”, a POST on /orders means “create a new order” and a DELETE on /orders/4711 means “delete this order”. These few, always identical verbs make a REST API quick to understand, because the pattern repeats across all resources.
Resources, HTTP verbs and status codes
Every REST API rests on three elements. First, the resources, which are addressed as nouns and in the plural – /products, /customers, /invoices. Second, the HTTP verbs GET, POST, PUT, PATCH and DELETE, which give the resources the meaning of reading, creating, replacing, partially changing or deleting. Third, the HTTP status codes with which the server reports the result: 200 stands for success, 201 for “created”, 404 for “not found” and 401 for “not authenticated”. Because these codes are uniform across the entire web, a calling system can clearly recognise whether a handover succeeded.
Statelessness and JSON
A central feature of REST is statelessness: the server remembers nothing about the client between two requests. Every request must therefore carry all the information it needs itself – in particular the access key for authentication. That sounds cumbersome, but it makes REST APIs robust and highly scalable, because requests can be distributed freely across many servers. The actual data is almost always transferred as JSON, a compact text format readable by both machines and humans, which has made JSON the de facto standard of modern web interfaces.
REST API vs. SOAP, GraphQL and webhook
REST is the dominant way to connect systems today, but not the only one. The older standard SOAP (see soap) wraps every message in a strictly defined XML format and brings extensive rules for security and transactions. SOAP is powerful but heavyweight; you still encounter it in established enterprise applications and in some public-authority interfaces. REST, by contrast, is considered leaner, easier to read and faster to connect, which is why newer ERP and shop systems almost universally offer REST.
GraphQL is a more recent approach in which the client specifies in a single request exactly which fields it needs – useful for bundling data volumes and avoiding anything superfluous. REST differs from a webhook in direction: with REST your own system actively asks for data (pull), whereas a webhook reports events on its own (push). In practice, many integrations combine both – REST for targeted data retrieval, webhooks for real-time notifications such as “new order received”.
The REST API in the ERP system
In the ERP, the REST API is the technical hub through which orders, stock levels, documents and master data move between systems. A cloud ERP provides endpoints for every important object – for products, orders, customers, delivery notes and invoices – which other programs use to read and write. This is how the ERP pulls new orders from shop and marketplace, pushes updated stock levels back, and hands documents in structured form to accounting. This inventory synchronisation across all channels is practically impossible to achieve without a robust API.
The quality of a REST API therefore decisively determines how well a system can be integrated. Key criteria in ERP selection are: publicly accessible documentation, complete coverage of the central objects, reliable status codes and well thought-out error handling. Where users do not want to program themselves, connectors, a middleware or an iPaaS platform handle the addressing of the REST endpoints in the background.
Authentication and rate limits
Because REST is stateless, the calling system must identify itself with every request – usually with an API key or a token following the OAuth procedure, which you set up once in the ERP. In addition, providers protect their REST APIs with rate limits, that is, upper bounds on the number of requests per time period. Anyone synchronising many records must respect these limits and bundle requests or spread them over time – a point that integration projects should plan for from the outset in order to avoid blockages during live operation.
Why REST APIs matter for merchants
For online merchants and mid-sized companies, the REST API is the lever for automating processes and keeping them scalable as volume grows. Without an interface, someone would have to type in orders, maintain stock in every channel individually and create shipping labels by hand – more expensive and more error-prone with every unit sold. Via REST endpoints, these handovers run automatically, in seconds and without media breaks.
Especially in a multichannel landscape with shop, several marketplaces, payment and shipping providers, an open REST API is often the criterion that decides the feasibility and cost of future connections. Systems with a closed or incomplete API quickly lead to vendor lock-in, because extensions can hardly be implemented technically. A strong REST API, by contrast, makes it possible to embed the ERP step by step into a growing system landscape.
Example
Example: keeping stock in sync via the REST API
A retailer of outdoor equipment sells through its own shop and two marketplaces. When it sells a tent footprint through the shop, the shop reports the order and the ERP retrieves it via a GET call to the /orders endpoint. The ERP reduces the stock level and pushes the new stock back to shop and marketplaces via a PUT on /products/{id}.
If the server returns status code 200, the ERP knows the update has arrived everywhere; on a 429 (“too many requests”) it waits briefly and repeats the call. This keeps stock in sync across all channels, and the dreaded oversell situation – where an already sold-out item is still offered – never arises in the first place, without any employee maintaining figures by hand.
Frequently asked questions
Related services
Questions about REST API in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.