New here? This page is a configuration reference for teams implementing the Syspro integration in iPaaS.com. It documents scope, design decisions, and settings to confirm before go-live. These are not product defects, and most items are handled during implementation by iPaaS.com or your Managed Integration Service Provider (MiSP). See Understanding Integration Scope & Known Limitations for how we document this for every integration.
Introduction
These are the known limitations of the Syspro integration. They are inherent to the current design of the integration and to the way Syspro exposes its data, and they apply to all subscribers at the time this documentation was written.
Platform Scope and Tested Versions
Built for: SYSPRO ERP, accessed through the Syspro REST API that is deployed alongside the subscriber's own Syspro installation.
Hosting: customer-hosted. There is no vendor-hosted or multi-tenant endpoint — each subscriber runs their own API instance, at a host they supply in the API Url subscription setting.
API versioning: the Syspro REST API used by this integration is not publicly versioned. The integration was built against the endpoints that API exposes, and its behavior therefore depends on the version of that API the subscriber has deployed rather than on a published version namespace.
Verification: this release was verified by code review against the integration and API source. It has not been validated end-to-end against a live or sandbox Syspro instance, because no partner sandbox is available for this platform. Subscribers should validate their own configuration in a staging environment before relying on it in production.
Not built for: other products in the SYSPRO range or from adjacent vendors are out of scope. This integration targets the Syspro REST API described above and nothing else. If SYSPRO launches a separate product line, or a materially different API generation, this integration will not automatically support it.
1. Bulk initialization is not supported
The integration does not support bulk initialization, so an existing Syspro customer base, product catalogue, or warehouse list cannot be loaded into iPaaS.com in a single operation.
What this means for you: first-time loading is done record by record, either by Manual Sync or by letting automatic transfers pick records up as they change. For an initial load of any size, use bulk sync using Postman — the supported pattern for moving a large dataset — and plan it as an implementation task rather than expecting a one-click import.
2. Automatic transfers depend on subscriber-hosted components
Automatic transfers are driven by database triggers in the subscriber's own Syspro database and a Windows relay service on the subscriber's own server. Neither runs in iPaaS.com.
What this means for you: if the relay service stops, changes queue up in Syspro and are delivered when it restarts — nothing is lost, but nothing is timely either. Treat the service as monitored infrastructure. Enabling or disabling which events flow is a change to the Syspro database, not a setting in iPaaS.com.
3. Not every record type can transfer automatically
Automatic transfer coverage varies by record type, and is not uniform:
Customers, sales orders and invoices transfer automatically once the components are installed — these events are enabled in the shipped configuration.
Products and stock levels can transfer automatically, but are switched off by default. The triggers exist; no subscription row is created for them, so nothing is raised until one is added in the Syspro database.
Warehouses and product variants have no trigger at all, so they cannot transfer automatically under any configuration.
What this means for you: warehouses and variants are maintained by Manual Sync. For most subscribers this is not burdensome — warehouses are few and change rarely — but a warehouse added in Syspro will not appear in iPaaS.com until someone transfers it, and inventory for that warehouse will fail until it does. Enabling automatic product and stock transfers is an implementation task to raise with your MiSP.
4. Filtered records are skipped silently
Several collections carry filters that exclude records by design — gift-card-only orders, deposit and gift-card sub-orders, orders already complete or cancelled, and invoices whose sales order or customer has not yet reached iPaaS.com. Separately, the Syspro-side subscriptions carry their own SQL filters.
What this means for you: an excluded record produces no error. If an expected record is missing and the error log is empty, the cause is a filter rather than a failure. There are two filter layers to check — the mapping collection's filter in iPaaS.com, and the SQL filter on the Syspro subscription. The mapping collection articles document the first; your Syspro administrator or MiSP holds the second.
5. Sales order status coverage is incomplete
The set of Syspro order statuses the status write-back accepts and the set its status translation can convert are not currently identical. One admitted status has no translation entry, so orders in that state are picked up and then fail; one translated status is not admitted, so those orders never transfer.
What this means for you: do not rely on the write-back to reflect every Syspro status change. Review the shipped translation against the order statuses actually used in your Syspro configuration before go-live, and extend it to cover them. If orders are seen stalling in a particular Syspro status, contact iPaaS.com Support.
6. Several Syspro statuses collapse to one iPaaS.com status
The shipped translation maps four distinct Syspro order statuses onto Pending.
What this means for you: iPaaS.com will not distinguish between those stages. The raw Syspro status code is preserved separately on each transaction, so the detail is available for reporting or troubleshooting — but any automation keyed on the iPaaS.com status alone treats all four the same. If your workflow needs them distinguished, the translation can be extended to use other iPaaS.com statuses.
7. Sales orders are created in Syspro but not updated
The outbound sales order collection creates orders. It does not update an order once it exists in Syspro.
What this means for you: a change made to the order in iPaaS.com after it has transferred does not reach Syspro, and the two records diverge. Amendments should be made in Syspro directly. Refunds, later payment captures and cancellations are likewise not carried across.
8. Deletions do not propagate in either direction
No entity in this integration implements delete. Removing a customer, product, warehouse, order or invoice in one system leaves the corresponding record in place in the other.
What this means for you: records removed at source remain in the destination until removed there too. Where obsolete records matter — for reporting accuracy or storefront display — plan a periodic reconciliation as an operational task.
9. Product status and type are fixed values
Every product transferred into iPaaS.com is written as Active and Physical, regardless of its state in Syspro.
What this means for you: an obsoleted Syspro item still arrives as Active, and a product previously disabled in iPaaS.com is set back to Active on its next transfer. A non-stocked or service item still arrives as Physical. Both are mapping values that can be replaced with a formula reading the relevant Syspro field — this is a normal implementation step where a subscriber's catalogue needs the distinction.
10. Invoices arrive as a different transaction type
Syspro invoices are captured into iPaaS.com as transactions of type Ticket, with status Complete, and carry their sales order number rather than the Syspro invoice number.
What this means for you: downstream systems and reports that filter transactions by type must look for Ticket to find invoices. An invoice later credited or adjusted in Syspro still shows as Complete — credits and reversals are not carried. If your reporting needs the Syspro invoice number, raise it during implementation.
11. Invoice lines carry quantities but not values
Invoice lines transfer the item, description and shipped quantity. Unit prices, discounts and tax are not captured at line level.
What this means for you: iPaaS.com shows what was shipped on each invoice line, but not what it was billed at. Where invoiced values are needed downstream, raise it during implementation.
12. Reference data must exist before dependent records transfer
Several transfers resolve a related record by name or by an existing link, and fail when it is missing:
Inventory requires a matching Location. Stock rows match the Syspro warehouse code against the iPaaS.com Location name — exactly, including case. A warehouse with no matching Location fails.
Sales orders require a linked customer. An order whose customer has never been synced cannot transfer.
Tracking requires a configured Shipping Method. The carrier value must match a Shipping Method configured in iPaaS.com.
Invoice lines resolve products by SKU. A line for an item never transferred arrives without a product association.
What this means for you: order of operations matters during implementation — warehouses before stock, customers before orders, products before invoices. The Shipping Method requirement is the one most often missed, particularly for invoice tracking, where the value comes from a free-text Syspro field that rarely matches a configured method without a translation.
13. Duplicate tracking records are possible
Order despatch and invoice despatch are captured by two separate collections. An order that is both despatched and invoiced can produce a tracking record from each.
What this means for you: decide during implementation which is the intended source of tracking information for your workflow, so customers are not shown two tracking entries for one shipment.
14. Placeholder Values to Replace Before Go-Live
The integration ships with example values that are correct for the environment it was built against and must be reviewed for yours.
Payment currency (Add Syspro Sales Order Payment FROM iPaaS.com)
Collection: Add Syspro Sales Order Payment FROM iPaaS.com
Shipped default: a dollar currency symbol, applied to every payment.
Why it's a placeholder: it is a fixed value, not read from the transaction, so it is correct only for subscribers trading in a dollar currency.
Suggested action: subscribers trading in any other currency must change it before enabling the collection, or every payment is recorded against the wrong currency. Where payments are taken in more than one currency, replace the fixed value with a formula reading the currency from the transaction.
Payment result code (Add Syspro Sales Order Payment FROM iPaaS.com)
Collection: Add Syspro Sales Order Payment FROM iPaaS.com
Shipped default: a fixed value indicating a successful payment.
Why it's a placeholder: because it is fixed, a pending, declined or partially captured payment is still recorded in Syspro as successful.
Suggested action: where orders can carry such payments, replace it with a formula deriving the result from the payment status.
Sales order type (Add Syspro Sales Order FROM iPaaS.com)
Collection: Add Syspro Sales Order FROM iPaaS.com
Shipped default: a fixed Syspro order type applied to every order.
Why it's a placeholder: order types are configured per Syspro environment, so the shipped code may not exist in yours.
Suggested action: confirm the code is valid in your Syspro configuration, and change it if your environment uses a different one for orders of this kind.
Syspro subscription filters (sales orders and invoices)
Collection: applies to the Syspro-side event subscriptions, not to an iPaaS.com mapping collection.
Shipped default: SQL filter conditions referencing a specific salesperson code, branch and reference values.
Why it's a placeholder: these are one customer's business rules, shipped as the default.
Suggested action: review and adjust them to match your own Syspro configuration before go-live. Left unchanged they will silently exclude most or all of your orders and invoices, and because filtered records are skipped rather than failed, nothing appears in the error log to indicate why. Your Syspro administrator or MiSP applies this change.
This document covers 14 known limitations. For detailed technical documentation on each mapping collection — including field mappings, filters and prerequisites — see the mapping collection descriptions in the Help Center.