Acumatica has shipped two generations of contract-based web services: an older SOAP API (screen-based web-service endpoints defined in the Integration Scenario / SOAP screen contracts) and the newer REST API. Both are "contract-based" in the sense that they expose defined fields and actions rather than raw tables — the difference is age, tooling, and what each one is still actually good for.
Two APIs, two different ages
The SOAP API predates the REST API by several major versions and was the only integration option for a long time. Acumatica has not been actively adding new capability to it — new features (OAuth 2.0, OpenAPI/Swagger generation, richer OData-style querying) have landed on the REST side. That alone should push most new work toward REST by default.
What the SOAP API still does well
SOAP contracts map very directly to screens and their exact field layout, including some legacy automation (older Excel add-ins, older middleware connectors, some third-party EDI tools) that was built against the SOAP endpoint and never migrated. If you're maintaining an existing integration built on it and it's stable, there's rarely a reason to force a rewrite purely for REST's sake — "it already works" is a legitimate reason to leave it alone.
A working SOAP integration that nobody's touched in years isn't automatically a liability. The cost of migrating it to REST only pays for itself if you also need something REST offers that SOAP doesn't — OAuth 2.0, easier testing tools, or a field the current contract can't expose.
Where REST wins
REST wins on tooling and auth. OAuth 2.0 bearer tokens are simpler to manage across a fleet of services than SOAP's session-cookie-plus-WS-Security patterns. JSON is friendlier to modern client libraries and to no-code tools (Zapier, Make, n8n) than a SOAP envelope. And because contract-based REST endpoints can generate an OpenAPI/Swagger document per version, you get typed client generation and interactive documentation essentially for free — nothing equivalent exists for the SOAP contracts.
Migration friction points
Moving an integration from SOAP to REST isn't a drop-in swap. Field names and nesting in the JSON contract don't always mirror the SOAP schema one-to-one, custom fields added to a SOAP contract need to be re-added to the REST endpoint separately, and any code relying on SOAP-specific behavior (strongly typed proxy classes generated from WSDL, for instance) needs to be rewritten against the JSON/OpenAPI model rather than just repointed at a new URL.
A decision rule
Build new integrations on REST. Leave a working SOAP integration alone unless it needs a capability only REST provides, or the tooling maintaining it (an old middleware version, an unsupported add-in) is itself being retired. The API choice should follow from what the integration needs, not from a blanket "SOAP is legacy, replace it" instinct — a stable SOAP-based nightly export that nobody touches costs nothing to leave in place.
Wrapping up
SOAP and REST are both still supported, but only one of them is getting new capability. Default new work to REST for its OAuth 2.0 support and OpenAPI tooling, and reserve SOAP-to-REST migration effort for integrations that actually need what REST offers rather than doing it on principle.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.