Introduction
These are the known limitations of the iPaaS.com Zuper integration. They are inherent to the current design of the integration and the capabilities of the Zuper API, and they apply to all subscribers at the time this documentation was written.
Platform Scope and Tested Versions
Platform: this integration is built for Zuper field service management.
API base URL: Zuper's API base URL is region-specific and is discovered per account through the Zuper Config API (for example, https://us-west-1c.zuperpro.com/api). See the Zuper API Endpoints article.
API version: Zuper does not publish a stable, versioned public API namespace; the integration was built against Zuper's documented production endpoints as of the date this documentation was written.
Not built for: this integration targets Zuper only. It is not built for other products or a materially different Zuper API generation; if Zuper introduces either in the future, this integration will not automatically support it.
Record Deletion
Most entities are created and updated only; they are not deleted through the integration. Removing a customer through the integration deactivates the customer in Zuper rather than permanently deleting it. Products, locations, employees, and billing records are not deleted by the integration.
What this means for you: manage record deletion directly in Zuper. The integration keeps existing records in step but does not remove them.
Initialization
Bulk initialization is supported only for Location data. All other data types are synchronized individually through automatic triggers, webhook events, or Manual Sync rather than a one-time bulk import.
What this means for you: to bring existing records into step for the first time, use Manual Sync or let the automatic triggers process records as they change, except for Locations, which can be initialized in bulk.
Automatic Transfers and Webhooks
Collections that send data to Zuper (the FROM iPaaS.com direction — customers, employees, products, inventory, and locations) do not use Zuper webhooks. They are driven by iPaaS.com outbound triggers and Manual Sync. Collections that capture data from Zuper (the TO iPaaS.com direction — invoices, deposit tickets, and jobs) support Zuper webhooks, which are enabled under Inbound Data Flows.
What this means for you: enable the relevant outbound triggers or inbound webhook events for the directions you use; until then, records transfer only through Manual Sync.
How Updates Overwrite Data
When the integration writes an updated record to Zuper, only the fields that are mapped and have a value are sent; fields that are not mapped are left untouched on the Zuper record. Mapped fields are overwritten on each transfer, so the source system is the source of truth for the fields you map.
Billing Records Share One Transaction Type
Invoices, deposit tickets, and jobs are all captured into iPaaS.com as transactions and are separated by filters: deposit tickets are identified by an invoice number ending in -D, standard invoices exclude those and drafts, and jobs are captured from Zuper jobs. Each has its own capture collection.
What this means for you: review the filters on the invoice, deposit ticket, and job collections together so each type is captured by the collection intended for it.
Records That Must Exist in Zuper First
Some transfers depend on related records already existing in Zuper:
A product category must exist in Zuper before a product can be created.
A product and a location must exist in Zuper before that product's inventory can be updated.
A Zuper role must exist for the role assigned to new employees.
What this means for you: create or confirm these records in Zuper before enabling the collections that depend on them, or the affected transfers will fail.
Child Records Transfer With Their Parent
Addresses, line items, notes, tax, and payment records are captured or written as part of their parent customer, invoice, deposit ticket, or job transfer. They do not transfer on their own. The one exception is standalone product stock updates, which have their own collection.
Placeholder Values to Replace Before Go-Live
The default mappings ship with placeholder or example values that each subscriber should review and replace for their environment:
Where | Placeholder value | Replace with |
Add/Update Zuper Product FROM iPaaS.com — Category | A fixed Zuper product category id | A real product category id from your Zuper account (required, or product creation fails) |
Add Zuper Employee FROM iPaaS.com — RoleId | 3 | The correct Zuper role id for new users in your account |
Add Zuper Employee FROM iPaaS.com — Designation | Technician | The job title your users should receive, or a mapped source value |
Add Zuper Employee FROM iPaaS.com — Password | The user's email address | A value that meets your security policy, or have users reset it after creation |
Add/Update Zuper Location FROM iPaaS.com — Type | SITE | Your Zuper location type, if different |
Add Zuper Job Payment Due TO iPaaS.com — Amount | 0 | A mapped source value if you want to record an actual outstanding amount for jobs |
Summary
This document covers ten limitation areas of the Zuper integration. For detailed technical documentation on each collection, see the mapping collection descriptions in the iPaaS.com mapping pages.