See what the Acumatica integration can do →

This article catalogs the Acumatica endpoints the iPaaS.com integration calls, grouped by entity. It is a reference for understanding which parts of your Acumatica instance the integration touches — useful for firewall and API-access configuration, for checking whether an Acumatica change affects the integration, and for troubleshooting. Every call is governed by your Acumatica instance's user permissions, licensing, and request limits.

The integration uses the Acumatica Contract-Based REST API (Acumatica product help, accessed 2026-06-26). All endpoint paths below are written against a single environment-agnostic base address:

Because each Acumatica environment is different, your base address and version may differ from another subscriber's; the integration uses whatever you configured. Records are read on a recurring poll and on demand via Manual Sync; records written from iPaaS.com are sent when an Outbound Data Flow trigger fires or a Manual Sync runs. Acumatica does not push changes to iPaaS.com — there are no webhooks.

Customers move in both directions: captured from Acumatica into iPaaS.com and written from iPaaS.com into Acumatica. Customer addresses are carried as children of the Customer.

Used to link an incoming record to an existing Acumatica Customer. The integration searches each contact type in turn — billing, shipping, primary, then main — until a match is found.

{ContactType} is one of BillingContact, ShippingContact, PrimaryContact, or MainContact.

Acumatica's Contract-Based REST API uses PUT as an upsert: the integration matches on the customer identifier and updates the existing record when one is found, or creates a new one when it is not.

On update, the same call is sent with an added &$filter=CustomerID eq '{CustomerID}' to target the existing record.

Stock Items are captured from Acumatica into iPaaS.com only (the integration does not write Stock Items back). Per-warehouse availability is captured through $expand=WarehouseDetails.

Reference lookups read from Acumatica into iPaaS.com so that a Sales Order written into Acumatica carries tax data that matches how your instance is configured.

Sales Orders are written from iPaaS.com into Acumatica. A Sales Order's line items, addresses, tax details, and payments are written as children of the order through the $expand parameter.

An upsert: creates the order when it does not yet exist and updates it when it does.

Warehouses are captured from Acumatica into iPaaS.com only.

Shipment endpoints carry tracking data, which moves in both directions and is also handled as a child of the Sales Order.

Writes an inventory issue into Acumatica to record an inventory adjustment.

The integration authenticates with OAuth 2.0 against your Acumatica instance. Tokens are obtained and refreshed automatically using the credentials in your subscription settings. The OAuth endpoints are at the instance root (not under the entity base address):

Which flow is used depends on the Grant Type setting (authorization_code for the browser-based flow, password for the resource-owner flow). See the Acumatica Connections and Settings article for how these values are supplied.

The integration is scoped to the entities above. Some other Acumatica record types are not supported and should not be expected to transfer — in particular, Acumatica invoices and purchase orders are out of scope, and non-stock items are not captured. For the full list of boundaries, see the Acumatica Known Limitations article.

Endpoints reflect the integration's use of the Acumatica Contract-Based REST API (Acumatica product help, https://help.acumatica.com, accessed 2026-06-26). Path availability, request limits, OAuth configuration, and the contract version are governed by your own Acumatica instance.