Acumatica API Gateway Pattern

Once an Acumatica instance has more than two or three external integrations hitting its REST API, an e-commerce sync, a mobile app, a partner-facing feed, an internal BI pull, I start recommending a gateway in front of Acumatica rather than letting every consumer hit the instance's REST endpoint directly. Not because Acumatica's API can't handle the traffic, but because the operational problems that show up at that point (per-consumer rate limiting, key rotation, consistent auth, request logging for debugging a specific partner's complaint) are gateway problems, not ERP problems, and trying to solve them inside Acumatica customization code is fighting the wrong layer.

What actually goes wrong without a gateway

The failure mode I've seen most: one integration partner's misbehaving retry logic hammers the Acumatica REST API hard enough to slow down the interactive UI for actual users on the same instance, because there was nothing between the partner and Acumatica's own request pipeline to absorb or throttle it. Acumatica's REST API doesn't give you fine-grained, per-consumer rate limiting out of the box, you get instance-wide behavior. A gateway in front lets you cap that one partner without touching Acumatica configuration at all, and without their bad behavior degrading the experience for internal users on the same box.

The shape I actually deploy: Azure API Management or a lightweight reverse proxy, not a full service mesh

For most Acumatica clients this is over-engineering to reach for a service mesh, there's one backend (Acumatica) behind the gateway, not a fleet of microservices needing mutual TLS and traffic shaping between each other. A straightforward API gateway product (Azure API Management is what I use most, since most of my clients are already on Azure; Kong or a simple Envoy config work equally well for AWS-hosted clients) sitting in front of the single Acumatica REST endpoint covers what's actually needed:

<policies>
  <inbound>
    <rate-limit-by-key calls="60" renewal-period="60"
        counter-key="@(context.Subscription.Id)" />
    <!-- Gateway holds the real Acumatica API user credential;
         partners never see it, only their own subscription key -->
    <set-header name="Authorization" exists-action="override">
      <value>@("Bearer " + context.Variables["acumatica-token"])</value>
    </set-header>
    <set-backend-service base-url="https://erp.client.com/entity/Default/24.200.001" />
  </inbound>
</policies>

Each external partner gets their own subscription key against the gateway, never a direct Acumatica API user credential. This means revoking one partner's access is a gateway-side key revocation, not an Acumatica user deactivation that risks touching audit trails or other integration dependencies tied to the same credential.

Centralizing the Acumatica auth so partners never see it

Acumatica's REST API auth (cookie-based session or OAuth bearer, depending on how you've configured it) is something I keep entirely behind the gateway. The gateway authenticates to Acumatica once, using its own service credential, caches the session or token, and refreshes it on expiry, external consumers authenticate to the gateway with their own key and never touch Acumatica credentials directly. This makes credential rotation a non-event for consumers: rotate the gateway's Acumatica-facing credential, and every partner's integration keeps working without any change on their end, because they were never coupled to that credential in the first place.

Per-partner logging is the feature that pays for itself fastest

The single most useful thing a gateway gives me that raw Acumatica access logs don't: a clean per-consumer view of request volume, error rate, and latency. When a partner emails saying "your API is down," having Azure APIM's or Kong's per-subscription analytics open answers "is it actually down, or is it specifically their traffic pattern" in under a minute, instead of grepping IIS logs on the Acumatica instance trying to isolate one partner's traffic from everyone else's.

Wrapping up

An API gateway in front of Acumatica earns its keep once you have more than a couple of external consumers: per-partner rate limiting Acumatica doesn't give you natively, centralized credential management so partners never hold real Acumatica auth, and per-consumer observability that turns "your API is down" support tickets into a one-minute lookup. Keep it thin, auth, throttling, routing, logging, and resist letting business logic migrate into gateway policies where it becomes invisible to anyone working in the actual ERP customization.