Definition

ERP Gateway

An ERP gateway is the service inside a CRM that translates each supported ERP's wire format into a normalized JSON shape the rest of the CRM consumes. It is the architectural piece that makes live ERP reads (and an ERP-native CRM in general) practical.

Last updated

Definition

An ERP gateway is a service inside an ERP-native CRM that translates each supported ERP's wire format (OData, SuiteTalk, IDOs, SOAP BAPIs, REST APIs of various flavors) into a normalized JSON shape the rest of the CRM consumes. The gateway sits between the CRM's UI and the customer's ERP, handling per-ERP idiosyncrasies, authentication, rate limiting, retries, caching, and failure modes.

It is the architectural piece that makes live ERP reads (and an ERP-native CRM in general) practical at production quality.

What problem the gateway solves

The CRM UI wants to render a normalized Account view: customer, orders, items, pricing, contacts. The ERP exposes that data through a wire format that varies wildly per vendor:

  • SAP S/4HANA: OData v4 endpoints, with specific entity sets, query options, and pagination patterns.
  • NetSuite: SuiteTalk REST + SuiteQL, with token-based auth and concurrency governance.
  • Dynamics 365 BC: OData v4 against the BC company endpoint, OAuth via Entra ID.
  • Infor SX.e: IDO Runtime + legacy interfaces, session management, specific field naming conventions.
  • Epicor Prophet 21: REST + OData for modern surfaces, SQL Server reads for older surfaces.

Without a gateway, every CRM screen would have to know how to talk to every ERP. With a gateway, the CRM speaks one normalized shape, and the gateway adapts to whatever ERP is on the other side.

What the gateway is responsible for

  1. Translation. Map the CRM's normalized Account / Order / Item shapes to and from the ERP's actual wire format.
  2. Authentication. Per-tenant credentials, token refresh, secret rotation. Credentials are stored encrypted with per-tenant HKDF-derived keys.
  3. Caching. Short-TTL caches (30s for inventory, longer for less-volatile data) to keep latency low without becoming a second copy of the data.
  4. Rate limiting. Respect the ERP's own governance (NetSuite's concurrency limits, SAP's burst caps, etc.) so the CRM never trips the ERP's circuit breakers.
  5. Retry and backoff. Idempotent retries for transient failures, structured errors for non-transient ones.
  6. Custom field mapping. Detect ERP custom fields (NetSuite custbody_*, SX.e UDFs, BC custom columns) and map them into the CRM's JSONB custom-field surface automatically.
  7. Per-ERP edge cases. Each ERP has weird behaviors (drop-ship handling differs, ATP calculation differs, address normalization differs). The gateway absorbs all of it.

Where the gateway sits

Architecturally:

CRM UI / Assistant
        |
        | (normalized JSON: Account, Order, Item)
        |
   ERP Gateway
        |
        | (per-ERP wire format)
        |
     The ERP

The gateway is its own service (or set of services) separate from the main CRM Lambda. This separation is intentional:

  • ERP integration latency varies more than the CRM's own latency. Isolating it makes the rest of the CRM predictable.
  • ERP credentials need a different security posture than ordinary CRM data.
  • Some ERPs (older on-premise SX.e, for example) benefit from a customer-managed gateway container that runs inside the customer's network and tunnels to the CRM.

How the gateway differs from middleware (iPaaS)

This is the central question. A middleware product (Boomi, MuleSoft, Workato) is a generic data-pipeline platform. It can integrate any system to any other system, with the cost being that it holds a copy of the data and syncs on a schedule. That is the middleware-bridged CRM pattern.

A gateway is purpose-built for the CRM-ERP pair and reads live on demand. There is no schedule, no copy, no separate billing.

The trade-off: a gateway is per-ERP code that the CRM vendor maintains. Middleware is generic code that anyone can run. For B2B distribution use cases where the ERP list is finite (5-7 ERPs cover 90% of the market), the gateway approach is structurally better. For one-off heterogeneous integrations, middleware still wins.

How Factory Labs implements gateways

Factory Labs has first-party gateways for SAP, NetSuite, Dynamics 365 BC, Infor SX.e, and Epicor Prophet 21. Each gateway is a real product the team maintains, validated against the relevant ERP's release cadence.

Per-ERP gateway docs:

Further reading