Skip to main content

Supported Features Format

Use Supported Features as an Integrator

Updated over 2 weeks ago

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:

  1. On any Integration page, click the Supported Features icon in the toolbar.

  2. 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.

  • For Transactions: Sales orders, deposit tickets, and returns.

  • For Company Relationships: Parent-child relationships are included, but Company Customer Relationships are not Parent-Only Transfer

Additional Info

Captures prerequisites, configuration requirements, or edition-specific notes related to the data flow.

  • Plugin must be configured using the XYZ method.

  • Feature available for Enterprise Edition only.

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: {id} represents the primary identifier and must match the identifier defined by the API. The naming convention must remain consistent across all endpoints within the respective flows.

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

{{unique_identifier}}

Used when one identifier is sufficient to distinguish the entity.

Typed Identifier

{{unique_identifier}}|{{type}}

The suffix {{type}} indicates the context or category of the record (for example, {{location_id}}|service).

Composite Identifier

{{child_unique_identifier}}|{{parent_unique_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

{"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.

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

Did this answer your question?