Skip to main content

REST API

REST (Representational State Transfer) is the dominant architectural style for web APIs and, by extension, the default integration standard in the modern ERP environment. A REST API exposes business objects — customers, sales orders, items, invoices — as addressable resources that external systems read and modify over plain HTTP, almost always with JSON payloads. When an e-commerce platform pushes orders into the ERP, a shipping system pulls delivery data, or an iPaaS orchestrates flows between a dozen SaaS tools, REST endpoints are usually the contract underneath. For ERP buyers, the quality of a vendor's REST API has become a selection criterion in its own right (see API-first ERP).

Resources, verbs, and JSON

REST models each business object as a resource with a stable URL, for example /api/v1/customers/1042. The standard HTTP verbs carry the semantics: GET reads, POST creates, PUT replaces, PATCH updates selected fields, DELETE removes. HTTP status codes report the outcome — 200/201 for success, 400 for an invalid request, 404 for a missing resource, 429 when limits are hit. Payloads are JSON, which every integration platform, programming language, and low-code tool parses natively. This uniformity is the practical advantage: a developer who has consumed one well-designed REST API can navigate the next one quickly, which lowers integration cost compared to proprietary interface formats.

Authentication: OAuth 2.0 and API keys

ERP data is sensitive, so authentication design matters. The current standard for system-to-system access is OAuth 2.0, typically the client-credentials flow: the integrating system exchanges a client ID and secret for a short-lived access token and presents that token on each request. Compared to static API keys, tokens expire, can be scoped to specific permissions (read-only item access, for example, without touching financials), and can be revoked without breaking every other integration. Many mid-market ERPs still offer simple API keys; acceptable for internal tooling, but scoping, expiration, and audit logging of API access should be part of any security review.

Rate limits, pagination, and versioning

Production APIs protect themselves. Rate limits cap requests per minute or per day; exceeding them returns HTTP 429, and well-behaved integrations back off and retry rather than hammering the endpoint. Pagination splits large result sets — no ERP returns 200,000 item records in one response. Versioning (such as a /v1/ path prefix) lets the vendor evolve the API without breaking existing integrations; the questions to ask are how long old versions stay supported and how breaking changes are announced. These operational details, not the endpoint list, decide whether an integration survives three years of ERP release cycles.

Webhooks vs. polling

REST alone is request-response: the consumer must ask. For event-driven scenarios there are two patterns. Polling queries the API on a schedule — simple and robust, but it wastes calls against rate limits and introduces latency of one polling interval. Webhooks invert the direction: the ERP calls a URL you register whenever an event occurs (order created, shipment posted), pushing near-real-time updates without wasted requests. Webhooks require the receiving side to be reachable and to verify signatures so forged calls are rejected, and a reconciliation fallback is still advisable because delivery can fail. Mature ERP APIs offer both; an iPaaS or middleware layer often handles retries, queuing, and transformation between the two.

REST vs. SOAP vs. GraphQL

SOAP is the older web-service standard: XML messages, WSDL contracts, and heavyweight tooling. It remains common in legacy ERP interfaces and some B2B scenarios, but new integrations rarely start there. GraphQL is the younger alternative: a single endpoint where the client specifies exactly which fields it wants, reducing over-fetching in data-rich UIs. In the ERP mid-market, GraphQL appears mostly in commerce and front-end contexts, while REST remains the lingua franca for system-to-system ERP integration. The three are not mutually exclusive — larger platforms expose REST and GraphQL side by side, with SOAP kept alive for legacy consumers.

Selection criteria for US buyers

  • API coverage: can every object you need — including custom fields — be read and written via the API, or do gaps force file-based workarounds?
  • Documentation quality: public, current reference documentation with examples and a sandbox tenant shortens every integration project.
  • Auth standard: OAuth 2.0 with scoped tokens should be available; clarify how credentials are rotated and how API activity is logged.
  • Rate-limit headroom: match published limits against your real volumes (order peaks, nightly syncs) and ask what raising them costs.
  • Webhook support: check which events can push notifications and how failed deliveries are retried.
  • Version policy: written commitments on deprecation timelines protect your integration investment across releases.

Comparable terms

A REST API is one concrete form of an API. API-first ERP describes systems whose entire functionality is built on their own public API. EDI solves structured B2B document exchange with formal standards and remains complementary to REST in retail and automotive supply chains. Middleware and iPaaS are the layers that consume REST APIs to orchestrate integrations at scale.

Related Topics