---
title: "ERP APIs Explained: What Each ERP Actually Exposes to an Ecommerce Integration"
url: https://www.uncap.com/post/erp-api-ecommerce-integration-guide
author: "Denis Dyli"
published: 2026-09-25
updated: 2026-09-25
---

# ERP APIs Explained: What Each ERP Actually Exposes to an Ecommerce Integration

> What P21, SX.e, Kinetic, SyteLine, M3, D365 F&O, Business Central, SAP Business One and Sage 100 actually expose to an ecommerce integration, and their limits.

"Does your ERP have an API?" is the wrong first question in an ecommerce project, because the answer is almost always yes and almost never useful. Every serious ERP exposes something. What matters is what kind of something: a modern REST service or a Windows component that has to run next to the server, a published rate limit or a ceiling nobody documents, business logic that runs when you call it or raw tables that let you write past it. Those differences decide how an integration is designed, how long it takes, and where it breaks. This is the plain version, system by system, of what nine common B2B ERPs actually expose.

**Quick answer:** An ERP API is the interface an outside system, such as an ecommerce storefront, uses to read and write ERP data like products, prices, inventory, customers, and orders. The surfaces differ sharply: Epicor Prophet 21 uses the P21 Middleware; Infor SX.e publishes a Service Interface REST API; Epicor Kinetic has an open REST API that can expose BAQs and Epicor Functions; Infor SyteLine generates REST endpoints from IDOs through Mongoose; Infor M3 uses the M3 API Gateway and ION; Dynamics 365 Finance and Operations exposes OData with published service protection limits; Business Central has a first-party Shopify connector plus its own API limits; SAP Business One uses the Service Layer; and Sage 100 has no REST API at all, only the COM-based Business Objects Interface and a narrow SOAP web service. Three questions sort any of them: what the surface is, whether its limits are published, and whether writes run the ERP's own business logic.

## Three questions to ask of any ERP API

**What is the surface?** REST, OData, SOAP, COM, or a vendor gateway. This decides whether a cloud service can call the ERP directly or whether something has to run inside your network, and it shapes authentication, hosting, and who operates the integration afterward.

**Are the limits published?** Some vendors document exact throughput ceilings; others publish nothing. A published limit lets an integration be sized on paper. An unpublished one means the sync has to be instrumented and measured on your instance, and any partner quoting a specific number without a source is guessing.

**Do writes run business logic?** An order written through a transaction service passes the ERP's own validation: credit checks, pricing rules, required fields. A row written underneath the application does not. The first is an integration; the second is a future reconciliation problem.

## Epicor Prophet 21: the P21 Middleware

Prophet 21 exposes its data through the P21 Middleware, which carries three distinct APIs rather than one. Data Services is based on OData version 4. Transaction API Services handles writes that have to respect P21's own business logic, which is where storefront orders belong. Entity REST Services sits alongside both.

Two details surprise first-time P21 projects. Each customer's API reference is self-hosted at their own middleware address, behind their own login, so there is no public reference anyone can send you. And Epicor publishes no rate limit or throttling threshold for P21, so the sync is designed to your volumes and measured. Prophet 21 2026.1, generally available on 2 June 2026, moved the backend to .NET 10 and added bulk data API capabilities, which matters for catalog refreshes. The full breakdown is on [the Epicor Prophet 21 integration page](https://www.uncap.com/integration/epicor-prophet-21).

## Infor SX.e: the Service Interface REST API

Infor publicly documents the Service Interface REST API Service for Distribution SX.e and CloudSuite Distribution, one of the better documented surfaces in wholesale distribution. Authentication is configured in SA Application Integration Endpoint, using an application ID, with sxapi as Infor's own example, and either Bypass OAuth Security or OAuth 2.0 with Authorization Code, Client Credentials, Password, or Refresh Token grants. On a CloudSuite tenant, that endpoint is normally set up by Infor Cloud Service; on-premises installs configure it themselves.

Pricing has its own named ION API endpoints, sxapiPDPricingAllMnt for pricing records and sxapiPDPriceSheetMnt for price sheets, with the same validation as a PD Mass Maintenance spreadsheet import and three documented error categories: Fatal, PDEM, and Duplicate. Infor publishes no rate limit for these endpoints. Details, including Infor's guidance to add pricing records rather than overwrite them, are on [the Infor SX.e integration page](https://www.uncap.com/integration/infor-sx-e).

## Epicor Kinetic: an open REST API, plus BAQs and Functions

Epicor documents an open REST API for Kinetic in which all Kinetic services, including business objects, processes, reports, BAQs, and Epicor Functions, are reachable through REST endpoints. It is OData based, authenticated with API keys and access scopes, and Kinetic ships interactive REST help inside the application so each instance can show exactly what it exposes.

The practical strength is that integration-shaped data can be defined inside the ERP: BAQs shape queries such as an available-to-sell figure that nets out jobs and allocations, and Epicor Functions hold custom server-side logic that survives upgrades. The practical limits are that Epicor's detailed developer documentation sits behind login and no rate limit is published. More on [the Epicor Kinetic integration page](https://www.uncap.com/integration/epicor-kinetic).

## Infor SyteLine: IDO REST through Mongoose

SyteLine, also sold as CloudSuite Industrial, is built on Infor's Mongoose framework, where business logic lives in IDOs, Intelligent Data Objects that encapsulate data and the logic that acts on it. Mongoose includes a REST API Wizard that generates REST endpoints from IDOs, with Swagger documentation, reachable directly or through the ION API gateway.

Which path fits depends on deployment, multi-tenant CloudSuite Industrial or on-premises SyteLine, and that is the biggest scoping variable on the project. The exact authentication mechanism for IDO REST is not confirmed in Infor's public documentation beyond authorization for Runtime Builder forms, so it is established on your instance rather than assumed. The detail is on [the Infor SyteLine integration page](https://www.uncap.com/integration/infor-syteline).

## Infor M3: the M3 API Gateway and ION

M3's integration surface is the M3 API Gateway and ION, with M3 API transactions, the MI programs, exposing the pricing, order, and inventory logic a wholesale integration needs. M3 is also the only Infor product with an official Shopify connector, built on Infor OS componentry.

The connector's own documentation describes it as a basic integration for a business-to-consumer model: inventory arrives as a daily net-change stock file with no interactive API and no future available-to-promise, every Shopify account maps to one M3 customer ID, and there is no release for M3 13.4 on-premises or single-tenant. For wholesale, the connection is built against the API Gateway and ION instead. See [the Infor M3 integration page](https://www.uncap.com/integration/infor-m3).

## Dynamics 365 Finance and Operations: OData and service protection limits

F&O publishes data entities over OData version 4 at the environment address plus /data, authenticated with Microsoft Entra ID. Two query limits shape design: $expand works to one level only, and server-driven paging caps a response at 10,000 records. Cross-company queries require the cross-company=true parameter, which matters as soon as more than one legal entity is in scope.

Microsoft also publishes its service protection limits, which few ERPs do: in a 300-second sliding window, per user, per application ID, per web server, the ceilings are 6,000 requests, 1,200 seconds of combined execution time, and 52 concurrent requests, with HTTP 429 beyond any of them. The two main ceilings balance at 200 milliseconds of server time per call, so slower calls hit the execution budget first. Bulk catalog work belongs in the Data Management Framework, with throttling priorities set so a batch job cannot starve checkout, as covered on [the Dynamics 365 Finance and Operations integration page](https://www.uncap.com/integration/dynamics-365-finance-operations).

## Business Central: a first-party connector and published API limits

Business Central is the only system here where the vendor ships its own Shopify connector: first-party, included with BC online at no extra license cost, preinstalled on new environments, with source published on GitHub. It syncs products, inventory across locations, customers and companies, orders including B2B, fulfillments, payouts, and posted invoices. It is online only; on-premises Business Central cannot use it.

Business Central online publishes its API limits too: 6,000 requests per five-minute sliding window before HTTP 429, a maximum of five concurrent requests, a 503 for queued requests waiting longer than eight minutes, a 100-connection cap and a request queue of 95, and an eight-minute operation timeout returning 408. The five-request concurrency limit is usually the real constraint. The connector's documented gaps, and the recurring Shopify API version deadline it inherits, are on [the Business Central integration page](https://www.uncap.com/integration/dynamics-365-business-central).

## SAP Business One: the Service Layer

Business One exposes the Service Layer, a REST interface following OData, by default on port 50000 with a service root of the form https://host:50000/b1s/v1. It follows OData 3.x, with version 4 constructs in batch operations. Use the v1 path; a v2 path exists and is not supported.

Authentication is session-based: credentials are posted to the Login endpoint, which returns a B1SESSION cookie that must accompany every subsequent request, and a load balancer in front uses sticky sessions and can fail over between nodes. Throughput is governed by a setting called Maximum Threads per Load Balancer Member, whose default we could not verify against a citable source, so it is checked on each instance in week one. More on [the SAP Business One integration page](https://www.uncap.com/integration/sap-business-one).

## Sage 100: the Business Objects Interface and eBusiness Web Services

Sage 100 has no REST API. Its main integration surface is the Business Objects Interface, built on the Component Object Model, which is in-process and session-bound, so anything described as a real-time Sage 100 integration involves a Windows-side component running near the Sage server. That component is part of the build and part of ongoing operations.

The second surface is eBusiness Web Services, SOAP over IIS, whose scope is sales orders, customers, and customer contacts, with no inventory. Visual Integrator and ODBC handle bulk import and export. Tables of Sage 100 REST endpoints that circulate online describe something that does not exist, which is worth knowing before evaluating a proposal. The full account is on [the Sage 100 integration page](https://www.uncap.com/integration/sage-100).

## What the nine have in common

Read side by side, the surfaces differ more than the vendors' marketing suggests: two publish exact throughput ceilings, several publish none, one has no web API at all, and the best-documented surfaces sit in two very different places. What does not change is the design rule an ecommerce integration should follow on any of them. The ERP resolves price, availability, and credit with its own logic; the storefront asks and renders; writes go through the surface that runs business rules; and the sync is sized to real limits, published or measured.

That is how [Uncap Connect](https://www.uncap.com/products/connect) is built across these systems, and the per-system pages linked above are where each surface is covered in depth. Uncap has been a Shopify Platinum Partner since 2013, with 380+ storefronts launched on Shopify, including for manufacturers, distributors, and wholesalers. Talk to Our Experts and bring your ERP, its version, and whether it is cloud or on-premises, three facts that decide most of the integration design before anyone writes code.

## Frequently asked questions

### What is an ERP API?

An ERP API is the interface other systems use to read and write ERP data, such as products, prices, inventory, customers, and orders. In ecommerce, it is how a storefront gets account pricing and availability from the ERP and sends orders back. ERP APIs range from modern REST and OData services to SOAP web services and Windows COM interfaces.

### Does Sage 100 have an API?

Not a REST API. Sage 100 provides the Business Objects Interface, built on COM, which requires a Windows-side component near the Sage server, and eBusiness Web Services, a SOAP service covering sales orders, customers, and customer contacts only. Visual Integrator and ODBC support bulk import and export.

### What API does SAP Business One use?

The Service Layer, a REST interface following OData 3.x (with v4 constructs in batch operations), running by default on port 50000 at a service root ending in /b1s/v1. Authentication is session-based through a B1SESSION cookie returned by the Login endpoint.

### What are the Business Central API limits?

Business Central online allows 6,000 requests per five-minute sliding window before returning 429, with a maximum of five concurrent requests. Queued requests waiting more than eight minutes return 503, there is a 100-connection cap and a queue limit of 95, and operations time out after eight minutes with a 408.

### Which ERPs publish their API rate limits?

Of the nine systems covered here, Microsoft publishes exact limits for both Dynamics 365 Finance and Operations and Business Central. Epicor publishes none for Prophet 21 or Kinetic, Infor publishes none for the SX.e endpoints, and SAP Business One's practical ceiling is an instance-level load balancer setting rather than a published figure. Where no limit is published, the integration should be instrumented and measured.