Integration Settings:
Mapping Collection Type: Specifies the data type mapped from the iPaaS module, such as “Customer” or “Customer Category”.
Mapping Direction: Indicates the direction of data flow — either TO or FROM iPaaS.
Support: This field indicates which features are supported by the integration and which are not.
Example:
(For Transactions): Includes sales orders, deposit tickets, and returns.
(For Company Relationships): Includes parent-child company relationships. Company Customer Relationships are not included.
Parent-Only Transfer.
Additional Information: Use this field to capture any additional information related to the flow, such as prerequisites, configuration requirements, or edition-specific notes. Examples include: These ensure compatibility and successful implementation.
Examples:
The plugin must be configured using the XYZ method.
The external system must be set up according to ABC configuration guidelines.
Feature is available for Enterprise Edition only.
Supported exclusively in the B2B Edition.
Allow Initialization: Defines whether the integration supports initialization steps. For example, if you need to transfer product data and want to initialize location data beforehand, set this value to "Yes" if supported.
Collision Handling Supported: Indicates whether the data type supports collision handling, such as checking for duplicate products in the third-party system, re-linking product variants, and managing their dependent flows within iPaaS. If supported, set this value to Yes.
Custom Field Supported: If the data type allows handling of custom fields FROM iPaaS or TO iPaaS, set this value to Yes.
Independent Transfers: Specifies whether the data type supports independent execution of specific flows (e.g., transaction tracking FROM iPaaS). If so, select Yes.
Polling Supported: Indicates whether the integration supports polling in flows TO iPaaS. Select Yes only if the third-party platform does not support webhooks.
Records Matching Supported: If collision handling is not available for the data type, but the system applies checks for prerequisites, post-processing, or duplicate detection, set this value to Yes.
External Webhook Support: If the third-party platform supports webhooks for the specific data type in flows TO iPaaS, set this value to Yes. In this case, the polling feature should not be used.
Endpoints Utilized
Value Format:
[METHOD] /resource/{id}
Method:
GET|POST|PUT|DELETE|PATCHEndpoint:
/resource/{id}NOTE:
{id}represents the primary identifier and should match the identifier defined by the API. The naming convention must remain consistent across all endpoints within the respective flows.
Note Format:
This specifies the endpoint’s purpose in detail, including any relevant edge cases (e.g., “Deactivate a customer,” “Retrieve a customer,” “Update a customer”). The {id} placeholder represents the primary identifier property name as defined by the API.
Example Usage
Customer
Example 1:
Value:
POST /customerNote: Registers a new customer in Zuper.
Transaction Address
Example 2:
Value:
GET /invoice/{invoice_uid}Note: Retrieves transaction addresses from the Customer Address object using the Invoice UID.
Location
Example 3:
Value:
PUT /products/location/{location_uid}Note: Updates a product location.
External Data Format
Record External ID Formats
This defines how external IDs are constructed within iPaaS to uniquely identify records. The formats include:
{{unique_identifier}}
Represents a single unique identifier used to reference a specific record. This format is applied when one identifier sufficiently distinguishes the entity within the integration.{{unique_identifier}}|{{type}}
Represents a typed identifier where the suffix{{type}}indicates the context or category of the record. This differentiation is useful for distinguishing similar identifiers across different functional areas, for example:{{location_uid}}|serviceor{{location_uid}}|billing.{{child_unique_identifier}}|{{parent_unique_identifier}}
Represents a composite identifier combining both child and parent identifiers. This format is necessary when the record’s identity depends on its hierarchical relationship, such as a product variant (child) linked to a parent product.
The “|” symbol acts as a delimiter joining multiple identifiers within an external ID. Depending on the integration requirements, this delimiter may be replaced with any supported character in iPaaS.
Webhook External ID Formats
This section explains the JSON formats used to define identifiers in webhook payloads, including their types and hierarchical relationships:
{"id" : "{{id}}"}: Represents a single unique identifier.{"id":"{{id}}","Type":"{{Type}}"}: Includes an identifier alongside a type to specify the record’s category.{"child id":"{{child id}}","parent id":"{{parent id}}"}: Represents a child-parent relationship using two identifiers.
Note Format:
This note provides a comprehensive explanation of the primary identifier used within the API. This identifier is the record’s unique external reference and is crucial for maintaining data consistency across integrated systems.
In some cases, the external ID may include a type qualifier to indicate the specific context or classification of the record. For example:
{{location_uid}}|service{{location_uid}}|billing
In these cases, the suffix (e.g., |service, |billing) defines the nature or category of the referenced data, helping differentiate similar identifiers used across different business areas.
Additionally, when a single identifier is not sufficient to uniquely identify a record, the external ID may consist of multiple primary identifiers, typically concatenated using a delimiter such as a pipe (|) or an underscore (_). Examples include:
{{variant_id}}|{{product_id}}{{variant_id}}_{{product_id}}
These composite identifiers ensure precise mapping and synchronization of records, especially in scenarios involving hierarchical or relational data structures. This note helps clarify how these formats should be interpreted to support accurate data integration and consistency.
NOTE: These format values are what an end user must provide when initiating a manual sync.
Supported Method
Method:
Defines the supported operations for each data type. Available methods include:
Add/Update: Supports both creating and updating records TO or FROM iPaaS.
Delete: Supports deletion of records TO or FROM iPaaS.
Add: Supports only record creation TO or FROM iPaaS.
Update: Supports only record updates TO or FROM iPaaS.
Delete Triggered Update: Deletes a record TO or FROM iPaaS and triggers a subsequent update action.