API Gateway Patterns for ERP Integration: When to Use and When It's Overkill

TL;DR

• Bottom line: Put an API gateway in front of ERP APIs when you have 5+ consumers, need unified auth/rate limiting across multiple ERPs, or must expose ERP data to external parties. Skip it when your iPaaS already handles these concerns or you have a single point-to-point integration.
• Key limit: Gateway adds 5-50ms latency per hop and introduces a single point of failure unless deployed in HA mode — for internal-only integrations this overhead often exceeds the benefit.
• Watch out for: Double rate limiting — gateway rate limits stack with ERP-native limits (e.g., Salesforce 100K/24h, D365 6,000/5min), and the stricter one silently wins, confusing debugging.
• Best for: Centralized API management when 6+ applications consume ERP APIs, external partner access to ERP data, or multi-ERP environments needing unified monitoring.
• Authentication: Gateway handles consumer-facing auth (API keys, OAuth client credentials) but must still authenticate to each ERP using ERP-native OAuth/TBA — two auth layers, not one.

System Profile

This card covers the architecture pattern of placing an API gateway between API consumers and ERP backend systems. It is system-agnostic and applies to any ERP (Salesforce, SAP S/4HANA, Oracle ERP Cloud, Dynamics 365, NetSuite, Workday) with any gateway product (Kong, Apigee, AWS API Gateway, Azure APIM, SAP API Management). The card does NOT cover iPaaS-specific API management features (MuleSoft API Manager, Boomi API Management) — those are covered in the iPaaS comparison card.

API Surfaces & Capabilities

Comparison of what each gateway product offers for ERP API proxying.

Rate Limits & Quotas

Gateway vs ERP Rate Limits — The Coordination Problem

Gateway rate limits and ERP-native rate limits operate independently. Configure gateway limits to be stricter than ERP limits, or consumers hit opaque ERP errors instead of clean gateway 429 responses.

Per-Request Limits at the Gateway

Authentication

Two-Layer Auth Model

An API gateway creates a two-layer authentication architecture: the gateway authenticates the consumer; the gateway itself authenticates to the ERP.

Per-ERP Gateway Authentication

Authentication Gotchas

• Gateway API keys give a false sense of security — they protect the gateway, not the ERP. A leaked API key with cached ERP tokens = full ERP access. [src1]
• Azure APIM with managed identity to Dynamics 365 is the only zero-secret gateway-to-ERP pattern. All others require secret rotation. [src3]
• SAP API Management uses principal propagation to forward user identity through the gateway to S/4HANA — third-party gateways cannot replicate this without custom SAML assertion injection. [src5]

Constraints

• Gateway rate limits stack with ERP-native rate limits — set gateway limits below ERP limits or debugging becomes impossible
• AWS API Gateway has a hard 29-second timeout on REST APIs — ERP bulk operations that take longer will be cut off (use HTTP API type or ALB)
• Gateway cannot replace iPaaS transformation logic — it handles header/query rewriting but not multi-object data mapping between ERP schemas
• SAP API Management is built on OEM Apigee Edge (not Apigee X) — policies may differ from current Apigee X documentation
• Single-region gateway deployment means all ERP traffic routes through one region — adds latency for global ERP deployments
• Gateway subscription keys + ERP OAuth = two auth layers, not one — consumers must manage both unless the gateway fully abstracts ERP auth
• Gateway adds 5-50ms latency per request — for sub-100ms ERP API calls this can double response time

Integration Pattern Decision Tree

START — Should I put an API gateway in front of my ERP APIs?
├── How many applications/teams consume ERP APIs?
│   ├── 1 (single integration)
│   │   ├── Using iPaaS? YES → SKIP GATEWAY (iPaaS handles concerns)
│   │   ├── Using iPaaS? NO → SKIP GATEWAY (direct API simpler)
│   │   └── External partner access? YES → ADD GATEWAY (security boundary)
│   ├── 2-5 consumers
│   │   ├── All internal? YES → MAYBE (unified monitoring/auth)
│   │   ├── External partners? → ADD GATEWAY (security + per-partner rate limiting)
│   │   └── iPaaS already managing? → CHECK iPaaS API management first
│   └── 6+ consumers or external API program
│       └── ADD GATEWAY — this is the sweet spot
├── Which ERP?
│   ├── Salesforce → Gateway for auth consolidation; rate limiting secondary
│   ├── SAP S/4HANA on BTP → USE SAP API MANAGEMENT (native, principal propagation)
│   ├── SAP on-premise → ADD GATEWAY (reverse proxy)
│   ├── Dynamics 365 → USE AZURE APIM (managed identity, zero-secret)
│   ├── Oracle ERP Cloud → ADD GATEWAY (no built-in API management)
│   └── NetSuite → ADD GATEWAY only if >5 consumers
└── What does the gateway need to do?
    ├── Rate limiting only → CHECK if ERP native limits sufficient
    ├── Auth consolidation → ADD GATEWAY
    ├── Simple transform (header/query) → Gateway OK
    ├── Complex transform (object mapping) → USE iPaaS instead
    ├── Monitoring/analytics → ADD GATEWAY
    ├── API versioning → ADD GATEWAY
    └── Caching → ADD GATEWAY (reference data only)

Quick Reference: Gateway Product Decision Matrix

Step-by-Step Integration Guide

1. Assess whether a gateway is needed

Audit your ERP API landscape: count consumers, map auth flows, check if your iPaaS already provides API management. [src6]

# Audit checklist
# 1. How many applications call ERP APIs? If < 5 internal, gateway may be overkill
# 2. Do external partners need ERP data? If yes, gateway is mandatory
# 3. Does your iPaaS have API management? (MuleSoft API Manager, Boomi, SAP API Mgmt)
# 4. Which ERP systems? D365 = Azure APIM; SAP BTP = SAP API Mgmt
# 5. Timeout requirement? AWS API GW hard limit 29s (REST API type)

Verify: If < 5 internal consumers and iPaaS handles auth/rate limiting → skip the gateway.

2. Configure gateway-to-ERP authentication

The gateway must authenticate to each ERP using ERP-native credentials. This is the most error-prone step. [src3]

# Kong declarative config — Salesforce OAuth 2.0 JWT Bearer
services:
  - name: salesforce-api
    url: https://your-instance.salesforce.com
    routes:
      - name: salesforce-query
        paths:
          - /erp/salesforce
    plugins:
      - name: request-transformer
        config:
          add:
            headers:
              - "Authorization: Bearer $(cached_sf_token)"

Verify: curl -H "apikey: KEY" https://gateway.example.com/erp/salesforce/services/data/v62.0/limits → returns Salesforce API limits JSON.

3. Set rate limits below ERP native limits

Configure gateway rate limiting with 10-15% safety margin below ERP native limits. [src7]

# Kong rate-limiting plugin — Salesforce example
plugins:
  - name: rate-limiting
    service: salesforce-api
    config:
      minute: 60
      hour: 3500
      day: 85000        # 85K vs Salesforce 100K = 15% margin
      policy: cluster   # Cluster-wide counter, not per-node
      hide_client_headers: false

Verify: Send 65 requests in 1 minute → requests 61-65 return HTTP 429 with Retry-After header.

4. Configure circuit breaker for ERP backend

ERP systems have maintenance windows. A circuit breaker at the gateway prevents cascading failures. [src2]

# Kong upstream health checks (circuit breaker)
upstreams:
  - name: salesforce-upstream
    healthchecks:
      active:
        healthy: { interval: 10, successes: 3 }
        unhealthy: { interval: 5, tcp_failures: 3, timeouts: 3, http_failures: 3 }
      passive:
        unhealthy: { tcp_failures: 3, timeouts: 3, http_failures: 3 }

Verify: Simulate ERP downtime → gateway returns 503, stops sending requests, auto-recovers.

Code Examples

Python: Rate limit coordination checker

# Input:  ERP rate limit config, gateway rate limit config
# Output: Validation — are gateway limits safely below ERP limits

def validate_rate_limits(erp_limits: dict, gateway_limits: dict, margin: float = 0.15):
    """Ensure gateway rate limits are below ERP native limits with safety margin."""
    issues = []
    for window, erp_limit in erp_limits.items():
        gw_limit = gateway_limits.get(window)
        if gw_limit is None:
            issues.append(f"WARNING: No gateway {window} limit — ERP enforces at {erp_limit}")
            continue
        max_safe = int(erp_limit * (1 - margin))
        if gw_limit > max_safe:
            issues.append(f"DANGER: Gateway {window} ({gw_limit}) exceeds safe ({max_safe})")
        else:
            issues.append(f"OK: Gateway {window} ({gw_limit}) safely below ERP ({erp_limit})")
    return issues

sf_limits = {"daily": 100_000, "hourly": 5_000}
gw_limits = {"daily": 85_000, "hourly": 4_250}
for line in validate_rate_limits(sf_limits, gw_limits):
    print(line)

XML: Azure APIM policy for Dynamics 365

<!-- Azure APIM inbound policy — Dynamics 365 Dataverse proxy -->
<policies>
  <inbound>
    <rate-limit-by-key calls="5000" renewal-period="300"
      counter-key="@(context.Subscription.Id)" />
    <authentication-managed-identity
      resource="https://your-org.crm.dynamics.com" />
    <rewrite-uri template="/api/data/v9.2/{remaining}" />
    <set-header name="OData-MaxVersion" exists-action="override">
      <value>4.0</value>
    </set-header>
  </inbound>
  <backend>
    <forward-request timeout="120" />
  </backend>
  <on-error>
    <choose>
      <when condition="@(context.Response.StatusCode == 429)">
        <return-response>
          <set-status code="429" reason="Rate limit exceeded" />
          <set-header name="Retry-After" exists-action="override">
            <value>60</value>
          </set-header>
        </return-response>
      </when>
    </choose>
  </on-error>
</policies>

cURL: Test gateway-proxied ERP API

# Test Salesforce query through Kong gateway
curl -s -w "\nHTTP Status: %{http_code}\nTime: %{time_total}s\n" \
  -H "apikey: YOUR_GATEWAY_KEY" \
  "https://gateway.example.com/erp/salesforce/services/data/v62.0/query?q=SELECT+Id,Name+FROM+Account+LIMIT+5"

# Check rate limit headers
curl -s -D - -o /dev/null \
  -H "apikey: YOUR_GATEWAY_KEY" \
  "https://gateway.example.com/erp/salesforce/limits" \
  | grep -i "x-ratelimit"

Data Mapping

Gateway Responsibility vs iPaaS Responsibility

Data Type Gotchas

• Gateway caching of ERP responses can serve stale data — set Cache-Control: max-age based on data volatility (product catalog: 3600s, order status: 0s). [src1]
• Gateway body size limits (10MB on Apigee/AWS) may be smaller than ERP bulk API limits (150MB Salesforce Bulk API) — bulk operations must bypass the gateway. [src8]
• SAP OData $batch requests are multipart MIME — some gateways parse these incorrectly, corrupting changeset boundaries. [src5]

Error Handling & Failure Points

Common Error Codes

Failure Points in Production

• Gateway timeout < ERP timeout = orphaned transactions: Gateway times out at 30s, ERP completes write at 45s. Consumer sees 504 but ERP has the data. Fix: Set gateway timeout = ERP timeout + 5s; use idempotency keys for writes. [src2]
• Circuit breaker false positive on ERP maintenance: Scheduled maintenance triggers circuit breaker that stays open. Fix: Always configure active health checks alongside passive; set recovery interval to match maintenance window. [src2]
• TLS certificate rotation breaks gateway-to-ERP: ERP cert rotated, gateway trusts old cert. Fix: Use CA-bundle trust, not certificate pinning; 30-day cert expiry alerts. [src3]
• Stale cached tokens after ERP password reset: Admin resets integration user password; cached OAuth token still used. Fix: Implement token refresh on 401; don't cache tokens > 1 hour. [src3]
• Session affinity conflicts with ERP load balancing: Gateway pins sessions to one ERP node. Fix: Disable session affinity unless ERP requires it (e.g., SAP stateful RFC). [src5]

Anti-Patterns

Wrong: Using the API gateway as an integration platform

# BAD — treating the gateway like an ESB/iPaaS
# 200 lines of Lua/JavaScript doing: query SF, query SAP, join data,
# transform schema, apply business rules
# Result: unmaintainable, untestable, no error recovery

Correct: Gateway does routing and security; iPaaS does transformation

# GOOD — gateway handles proxy, auth, rate limiting only
services:
  - name: order-integration-api
    url: https://mulesoft.example.com/api/v1/orders  # Points to iPaaS
    plugins:
      - name: rate-limiting
        config: { minute: 60 }
      - name: key-auth
        config: { key_names: ["apikey"] }

Wrong: Double rate limiting without coordination

# BAD — gateway AND iPaaS AND ERP all enforce separate rate limits
# Consumer gets inconsistent 429 errors from different layers
# with different Retry-After values

Correct: Single rate limiting layer with ERP-aware limits

# GOOD — gateway is the ONLY consumer-facing rate limiter
# iPaaS rate limiting disabled; gateway limits set 15% below ERP
plugins:
  - name: rate-limiting
    config:
      day: 85000     # 15% below Salesforce 100K/24h
      policy: cluster
      hide_client_headers: false

Wrong: Gateway as single point of failure

# BAD — single gateway instance, no failover
# If this node dies, ALL ERP traffic stops

Correct: HA gateway with graceful degradation

# GOOD — multi-node cluster behind LB with direct-to-ERP fallback
upstreams:
  - name: erp-backend
    targets:
      - target: erp-node-1:443
      - target: erp-node-2:443
    healthchecks:
      active:
        healthy: { interval: 5, successes: 2 }
        unhealthy: { interval: 2, tcp_failures: 2 }

Common Pitfalls

• Treating gateway timeout as ERP timeout: AWS 29s hard limit is independent of ERP operation. Bulk import at 60s succeeds on ERP but consumer gets 504. Fix: Use async patterns (202 Accepted + polling) for long-running operations. [src8]
• Adding gateway to a single iPaaS integration: If MuleSoft/Boomi handles auth, rate limiting, monitoring already, gateway doubles cost and adds latency for no benefit. Fix: Use iPaaS built-in API management first. [src4]
• Caching ERP write responses: Gateway caches POST response; subsequent identical requests get cached "success" without reaching ERP. Fix: NEVER cache POST/PUT/PATCH/DELETE; only cache GET for reference data. [src1]
• Gateway logs contain ERP credentials: Request logging captures OAuth tokens in clear text. Fix: Redact Authorization headers and token fields; use log masking policies. [src7]
• Mixing SAP API Management with third-party gateway: Two competing API management layers with conflicting policies. Fix: Pick one: SAP for SAP-centric landscapes, or third-party for multi-ERP. [src5]
• Not handling ERP pagination through gateway: Gateway rewrites URLs, breaking Salesforce nextRecordsUrl or D365 @odata.nextLink. Fix: Preserve ERP pagination URLs in response rewriting rules. [src3]

Diagnostic Commands

# Check gateway health and upstream ERP status (Kong)
curl -s http://localhost:8001/upstreams/salesforce-upstream/health | jq '.data[].health'

# Check current rate limit counters (Kong)
curl -s http://localhost:8001/plugins | jq '.data[] | select(.name=="rate-limiting") | .config'

# Test gateway-to-ERP latency (difference = gateway overhead, should be < 50ms)
time curl -s -o /dev/null https://your-instance.salesforce.com/services/data/v62.0/limits
time curl -s -o /dev/null -H "apikey: KEY" https://gateway.example.com/erp/salesforce/limits

# Check Azure APIM metrics for D365 backend
az apim api show --resource-group RG --service-name APIM --api-id dynamics365

# Verify gateway TLS cert not expired
echo | openssl s_client -connect gateway.example.com:443 2>/dev/null | openssl x509 -noout -dates

Version History & Compatibility

When to Use / When Not to Use

Cross-System Comparison: API Gateway vs iPaaS API Management

Important Caveats

• Gateway products evolve rapidly — Kong, Apigee, and Azure APIM release quarterly. Verify rate limit and transformation capabilities against current documentation.
• Cost comparisons are approximate and depend heavily on request volume, deployment model, and support tier. Request vendor quotes for your specific throughput.
• SAP API Management is built on OEM Apigee Edge (not Apigee X) — Apigee Edge documentation may not match SAP's implementation. Always reference SAP-specific docs.
• AWS API Gateway REST API has a hard 29-second timeout that cannot be increased. Use HTTP API type (30-minute timeout) or ALB for synchronous bulk ERP operations.
• The decision to add a gateway should be driven by consumer count and external access requirements, not by a checklist of gateway features. Many organizations add gateways for capabilities their iPaaS already provides.