REST API

REST (Representational State Transfer) is the dominant API paradigm for modern ERP integration. REST APIs expose ERP resources (customers, orders, invoices, materials) through HTTP-based endpoints using standard verbs (GET, POST, PUT, PATCH, DELETE) and typically JSON payloads. Since the mid-2010s, REST has displaced SOAP and proprietary RPC approaches as the default integration mechanism for ERP and surrounding business applications.

REST principles

The core REST principles, articulated by Roy Fielding in his 2000 dissertation: (1) Client-server separation — UI and data layers are independent. (2) Stateless — each request contains all needed context; no server-side session state. (3) Cacheable — responses indicate their cacheability. (4) Uniform interface — consistent resource identification, manipulation through representations, self-descriptive messages, hypermedia (HATEOAS) where appropriate. (5) Layered system — intermediaries (proxies, load balancers, gateways) are transparent. (6) Code-on-demand (optional). In practice, most 'REST APIs' implement subsets of these principles — HTTP-based JSON APIs with sensible URL patterns, not strict-Fielding REST. The vocabulary persists nonetheless.

OData and GraphQL extensions

OData (Open Data Protocol): Microsoft-led REST extension adding rich query syntax in the URL ($filter, $select, $expand, $orderby, $top, $skip). Dominant in Microsoft Dynamics 365 and SAP S/4HANA cloud APIs. Reduces the number of API calls needed for complex queries. GraphQL: alternative API paradigm where the client specifies exactly what data is needed in a single request. Strong in modern web applications (Shopify, GitHub, Stripe), but less common in traditional ERP. JSON:API and HAL (Hypertext Application Language): REST conventions for consistent hypermedia patterns; popular in framework-specific implementations. For ERP integration in DACH, REST plus OData covers nearly all use cases; GraphQL is encountered mostly in modern e-commerce stacks integrating with ERP.

API security

Modern REST API security uses several layered controls. OAuth 2.0: the standard for authentication and authorisation, with flows for user-delegated access (authorisation code) and service-to-service access (client credentials). OpenID Connect (OIDC): OAuth 2.0 extension adding identity tokens; standard for user authentication. API keys: simpler credentials for service-to-service integration without user context. JWT (JSON Web Tokens): compact signed tokens carrying authorization claims. Rate limiting and throttling: enforced by API gateways to prevent abuse. mTLS: mutual TLS authentication for high-security integrations. Request signing: HMAC-based signatures for tamper-evident requests. ERP-specific: SAP S/4HANA Cloud uses OAuth 2.0; Microsoft Dynamics 365 uses Microsoft Entra ID OAuth; NetSuite and Oracle Cloud have their own OAuth implementations. Mid-market ERPs (weclapp, Xentral) typically support API keys plus OAuth where available.

Practical guidance for ERP API consumers

Three patterns for productive REST API integration with ERP. (1) Respect rate limits and design for throttling. ERPs publish rate limits (typically 1,000-10,000 requests per minute per tenant); exceeding them produces 429 Too Many Requests responses. Build backoff and retry logic from the start. (2) Use delta queries where available. Fetching full datasets repeatedly burns rate-limit capacity; OData $filter on modifiedDate, or specific change-tracking endpoints (Microsoft Dynamics 365 Data API, SAP CDS Delta View), enable incremental synchronisation. (3) Plan for ERP upgrades. API contracts evolve; deprecation windows of 12-24 months are typical for major vendors. Subscribe to the vendor's API change-notification feed and refresh integrations on a regular cycle.

Related Topics

• API-first ERP
• iPaaS
• Middleware