Why We Publish These Pages
Every iPaaS.com integration ships with a detailed Known Limitations page. Most platforms don't document their integrations to this depth. We do, on purpose. These pages let your team see exactly how an integration behaves before you implement it, with no surprises at go-live.
What "Limitation" Actually Means Here
The items on these pages fall into three buckets:
Design decisions: where the source platform owns a behavior by design (for example, NetSuite calculates tax and order totals from line items). This is correct behavior, not a shortfall.
Configuration to confirm before go-live: example values and control settings to set for your environment. Your implementation team handles these during onboarding.
True constraints: the few hard boundaries of a platform's API, each listed with its supported workaround.
The short version: Known Limitations pages document scope and design decisions. They are not lists of product defects.
Limitations vs. Errors vs. Unbuilt Features
A limitation is a documented boundary or design decision of the integration as it exists today.
An error is a runtime problem in a data transfer; those are surfaced in the error log with resolution guidance, not on limitations pages.
An unbuilt feature is functionality that could be added in a future version. Limitations pages will often note these explicitly so you can plan around them or request them.
Who Handles This
You don't work through these pages alone. iPaaS.com and your Managed Integration Service Provider (MiSP) configure the integration for your stack as part of implementation. Most items on any limitations page are handled for you during onboarding.
Evaluating an Integration?
Talk to us about your specific systems and data flows and we'll confirm scope for your use case. You can reach the team through the chat in your iPaaS.com account or at support@ipaas.com (for existing clients) or sales@ipaas.com for prospective ones.