Overview
This document serves as a comprehensive guide for understanding and using Supported Features in iPaaS.com integrations. It defines the essential settings, capabilities, and data exchange conventions required to build, configure, and maintain data flows.
Use this guide to understand how to map external data types, define the direction and supported operations of data transfers, and specify the formats for unique external identifiers and API endpoints.
Adhering to these structured definitions ensures maximum compatibility, successful implementation, and consistent data synchronization between the iPaaS.com module and any integrated third-party system. This section indicates which features are supported and which are not by the integration.
To access Supported Features:
On any Integration page, click the Supported Features icon in the toolbar.
On the Integration Supported Features page, click the edit icon for the feature you wish to view or edit.
Integration Settings
Field | Description | Example/Details |
Mapping Collection Type | Specifies the iPaaS.com data type mapped. | Customer, Customer Category |
Mapping Direction | Indicates the data flow direction. | TO iPaaS or FROM iPaaS |
Support | Indicates which features are supported by the integration. Provides common examples for the data type. |
|
Additional Info | Captures prerequisites, configuration requirements, or edition-specific notes related to the data flow. |
|
Advanced Functions
This section outlines whether specific advanced functionalities are supported by the integration for the defined data type.
NOTE: These settings are for informational purposes. They do not enable the settings. |
Field | Description | Supported Value |
Allow Initialization | Defines whether the integration supports initialization steps, such as initializing location data before a product data transfer. | Yes/No |
Collision Handling Supported | Indicates if the data type supports collision handling, such as checking for duplicates, re-linking variants, etc. | Yes/No |
Records Matching Supported | Often used if collision handling is NOT implemented. Indicates if the system applies other checks like matching on email for customers or product on SKU. | Yes/No |
Custom Fields Supported | Indicates if the data type allows handling of custom fields in the external system (TO or FROM iPaaS). | Yes/No |
Independent Transfers | For a child collection, specifies whether the data type supports independent execution of specific flows such as transaction tracking FROM iPaaS.com. | Yes/No |
Webhook and Polling Settings
Feature | Description | Note | Supported Value |
Polling Supported | Indicates if the integration supports polling in flows TO iPaaS. |
| Yes/No |
External Webhook Support | Indicates if the third-party platform supports webhooks for this data type in flows TO iPaaS. | If Yes, the polling feature should not be used. | Yes/No |
Endpoint Definitions
Endpoints Utilized
Value Format
iPaaS.com supports these methods: GET | POST | PUT | DELETE | PATCH.
The format is: [METHOD] /resource/{id}
NOTE: |
Note Format
A Note provides a comprehensive explanation of the endpoint’s purpose, including any relevant edge cases.
Example: Use to fetch the Sales Order from NetSuite.
External Data Type
This defines how an external ID, such as "Sales Order" in Oracle NetSuite, is used in a Transaction collection.
Value: The external data type.
Note: Explains what this type represents and how it is used.
External ID Formats
This section defines the formats for uniquely identifying records within the integration.
Record External ID Formats
This defines how external IDs are constructed within iPaaS to uniquely identify records.
Format | Structure | Purpose |
Single Identifier |
| Used when one identifier is sufficient to distinguish the entity. |
Typed Identifier |
| The suffix |
Composite Identifier |
| Necessary when a record’s identity depends on its hierarchical relationship (for example, a product variant linked to a parent product). |
NOTE: The pipe character is the default delimiter, but any other supported character may be used. |
External ID (JSON Formats)
This section explains the JSON formats used to define identifiers in the external system.
Format | Purpose |
| Represents a single unique identifier. |
| Includes an identifier alongside a type to specify the record’s category. |
| Represents a child-parent relationship. |
Important Notes on Identifier Usage: The primary identifier used in the API is the record's unique external reference. It is crucial for maintaining data consistency across all integrated systems. |
Typed Qualifiers: In some cases, the external ID may include a type qualifier such as |service to indicate a specific context or classification.
Composite Identifiers: When a single identifier is insufficient, the external ID may consist of multiple primary identifiers, typically concatenated using a delimiter (e.g., pipe | or underscore _). Example:
{{variant_id}}|{{product_id}}
NOTE: These format values are what an end user must provide when initiating a manual sync. |
Supported Method (Operations)
This defines the supported operations for each data type.
Method | Description | Supported Directions |
Add/Update | Supports 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 | Updates a record when presented with a delete hook. | TO or FROM iPaaS |






