Before You Begin
Syspro is customer-hosted, so three components run in the subscriber's own environment and must be installed before the integration can transfer anything. Unlike integrations with a vendor-hosted API, there is no account to register for and no API key to generate — but there is server-side work.
Plan for access to:
The Syspro database, with permission to create tables, triggers and functions. The supplied SQL scripts are applied here.
A Windows server that can reach both the Syspro database and the internet, to host the webhook relay service.
A host name reachable from iPaaS.com over HTTPS for the Syspro REST API.
An SSL certificate covering that host name. A wildcard certificate covering the subscriber's domain also works.
Firewall changes, to publish the API to iPaaS.com while keeping it closed to everyone else.
The person performing the installation is normally the subscriber's Syspro administrator or their MiSP, not the iPaaS.com subscriber alone.
SSL certificate
The Syspro REST API must be published over HTTPS on the host name entered in API Url, with an SSL certificate covering that host name. A wildcard certificate covering the subscriber's domain is equally acceptable.
Plan for renewal the same way as any other public certificate on the subscriber's estate — an expired certificate is a normal operational risk here, and the integration does not warn about certificate problems.
Firewall access
The Syspro REST API reads the Syspro database directly, so the allowlist on its address is what keeps the rest of the internet away from it. Publish the API so that iPaaS.com can reach it, and restrict inbound traffic to only the sources that need it.
The subscriber's IT team should allow inbound traffic to the Syspro REST API from:
Source | Address |
iPaaS.com production environment ( |
|
iPaaS.com staging environment |
|
The subscriber's own troubleshooting addresses | as required by the subscriber's IT team |
IMPORTANT: the API exposes Syspro data directly. Publishing it without an inbound allowlist exposes the Syspro database to the public internet. Treat the allowlist as a required part of the installation, not an optional hardening step.
Installation Instructions for Integration Setup
In iPaaS.com, go to Subscriptions and choose Search Certified Integration Marketplace.
Locate the Syspro product tile and open its details page.
Choose Subscribe.
Name the subscription using the convention
[Product Name] - [Environment/Purpose]— for exampleSyspro - ProductionorSyspro - Test.Leave Create Default Mappings checked so the subscription is provisioned with the standard Syspro mapping collections. Unchecking it creates an empty subscription with no mappings, which is only appropriate when the mappings are being supplied another way.
On the Subscription Settings page, enter the settings described below.
Choose Apply.
API endpoint entry
Enter the host where the Syspro REST API is reachable in API Url.
NOTE: Enter the host name only — for example syspro.example.com. Do not include https://. The integration adds the scheme itself, so a value that already carries one produces an unusable address and every call fails with a connection error.
Because the API is customer-hosted, there is no vendor-supplied test or production URL — both are whatever the subscriber has deployed. Subscribers running separate Syspro environments use a separate iPaaS.com subscription for each, pointed at its own host.
Throttle and concurrency
Setting | Recommended | Notes |
API Throttle Limit | 500 | Calls per throttle window to Syspro. |
API Throttle Seconds | 60 | Length of the window. |
API Throttle Limit (To iPaaS.com) | 500 | Calls per window to iPaaS.com. |
API Throttle Seconds (To iPaaS.com) | 60 | Length of the iPaaS.com-side window. |
Concurrent Connections | 2 | How many transfers run against Syspro at once. |
Concurrent Batch Executions | 10 | How many batch transfers run at once. |
Syspro does not itself impose a rate limit — these values protect the subscriber's own server. Lower Concurrent Connections and the throttle limit for a modestly-specified Syspro server, or during period-end processing.
Authentication Configuration
There are no credentials for the subscriber to obtain or enter. The integration authenticates to the Syspro REST API automatically: it requests an access token, caches it with its expiry, and renews it when it expires.
The only value that governs whether the connection succeeds is API Url. If the connection fails, the cause is almost always an unreachable host or a value entered with a scheme.
NOTE: Some subscriptions display an API Key field. It is not used by this integration — the connection does not depend on it, and leaving it blank has no effect.
Operational Configuration
Transaction Success Status
Field: Transaction Success Status
Description: The Syspro order status the integration writes back to a sales order after it transfers successfully.
Purpose: Lets Syspro users see, on the order itself, that it reached iPaaS.com — useful where Syspro staff work orders from a status-driven queue.
Example: setting this to a status your Syspro configuration uses for "sent to iPaaS.com" moves each order into that status once its transfer completes.
Recommended: leave blank unless the subscriber has a Syspro status set aside for this. When blank, no status write-back occurs and orders keep whatever status Syspro gave them.
Additional Configuration Options
Syspro REST API installation
Deploy the Syspro REST API against the subscriber's Syspro database.
Publish it over HTTPS on the host name to be entered in API Url, with an SSL certificate covering that host name (a wildcard certificate for the subscriber's domain also works).
Apply the inbound firewall allowlist described in Before You Begin, so the API is reachable by iPaaS.com and closed to everything else.
Confirm it is reachable over HTTPS from outside the subscriber's network at that host.
Confirm the availability endpoint responds before continuing.
Syspro database objects
The supplied SQL scripts create the objects that queue change events for the integration. Apply them to the Syspro database in the order supplied. They create:
a logging table,
an outbound event queue table,
database triggers on the Syspro tables the integration watches — customer, sales order, stock item, warehouse stock and invoice,
a subscription table controlling which events are actually raised.
IMPORTANT: the triggers check the subscription table before queuing anything. An event with no enabled subscription row is silently ignored — no event is queued and no error is raised. This is the mechanism that determines which automatic transfers work.
Which events are enabled by default
The shipped scripts enable customer, sales order and invoice events. Product and stock events are not enabled by default — the triggers exist, but no subscription row is created for them, so no product or inventory change reaches iPaaS.com until a row is added. Warehouse and product-variant changes have no trigger at all and cannot be automated; those records are transferred by Manual Sync.
IMPORTANT: the shipped subscription rows for sales orders and invoices carry example filter conditions reflecting one customer's business rules — a specific salesperson code, particular branch and reference values. Review and adjust these filters 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.
Syspro webhook service installation
Install the webhook relay service on a Windows server with access to both the Syspro database and the internet.
Edit appsettings.json in the service's own installation folder — the service reads this file from its working directory each time it starts, so it must sit alongside the executable.
Set the four values described below.
Start the service and confirm it is running.
Settings in appsettings.json
Setting | What to enter |
ConnectionStrings / DBContainer | A SQL Server connection string pointing at the subscriber's own Syspro database — the same database the SQL scripts were applied to. Either SQL authentication or a trusted connection works. |
IpaasHookBaseUrl | The iPaaS.com hook endpoint for the environment the subscription lives in. Confirm the correct value for your environment with iPaaS.com Support — the value shipped in the file points at a non-production environment and must be changed. |
IpaasSubscriptionToken | The subscription's webhook API key, copied from the Syspro subscription in iPaaS.com. |
LogSeverity | Controls how much the service writes to its log. Leave at the default for normal running; raise it when troubleshooting. |
DebugMode | Additional diagnostic logging. Leave off for normal running. |
Example
{
"ConnectionStrings": {
"DBContainer": "Server=YOUR-SQL-SERVER;Database=YourSysproDatabase;User Id=YOUR_SQL_USER;Password=YOUR_SQL_PASSWORD"
},
"IpaasHookBaseUrl": "https://<confirm-with-ipaas-support>/hookapi/v2",
"IpaasSubscriptionToken": "YOUR_SUBSCRIPTION_WEBHOOK_API_KEY",
"LogSeverity": "E",
"DebugMode": false
}IMPORTANT: the file ships with example values from the development environment, including a database server name, a SQL password and a subscription token that belong to another environment. Every one of them must be replaced. Left unchanged, the service will attempt to connect to a database that does not exist on the subscriber's network, and would relay events to the wrong subscription if it could reach one.
NOTE: the file also contains MonitoredSystemName and PollInterval entries. Neither is read by the service, so changing them has no effect.
The service drains the event queue and relays each event to iPaaS.com. While it is stopped, changes accumulate in the queue and are delivered when it resumes — they are not lost, but they are not timely either.
Post-Installation Verification
Connection Test
Confirm the Syspro REST API is reachable at the configured host, and that no connection error appears under Dashboard / Integration Monitoring / Error Logs.
Data Sync Test
From the iPaaS.com Manual Sync page, transfer a single Syspro warehouse. Confirm a Location appears in iPaaS.com whose name matches the warehouse code exactly.
Transfer a single Syspro stock item. Confirm the product appears with its stock quantities against the correct Location.
Transfer a single Syspro customer. Confirm the customer appears with its account number and email address.
Transfer warehouses before products — inventory rows resolve their Location by matching the warehouse code against the Location name, and fail if no Location matches.
Functionality Test
With the webhook service running, change a customer record in Syspro and confirm the change reaches iPaaS.com without a Manual Sync. If it does not, confirm the service is running and that the customer events are enabled in the subscription table.
Error Messages
The errors most often seen during installation:
Failed attempting to login to the Syspro Api: the API is reachable but rejected the login. Confirm it is running and healthy on the subscriber's server.
A connection error naming the host: the API could not be reached at all. Confirm the host in API Url is correct, reachable, and entered without
https://.An error naming a required field: a record could not be written because a required value was missing. The mapping collection articles document which fields are required for each record type.
The full catalog is in the Syspro Error Messages article.
Support and Troubleshooting
Support Portal: https://support.ipaas.com/en/
Contact Information: https://ipaas.com/contact-us/
For the Syspro REST API, database scripts or webhook service, the subscriber's Syspro administrator or MiSP is the first point of contact, since all three run in the subscriber's own environment.