iPaaS.com Core Concepts and Terminology

As an Integrator, you have access to specific features within the platform. You can also switch between Subscriber and MiSP roles to access additional functionality as needed.

The Integrator experience is configured at the company level and provides specialized permissions for developers who create and deploy subscriptions. This role-based experience includes specific tools and features designed for integration development. You can switch to a Subscriber view to test your implementations.

iPaaS.com serves as the central source for all API calls made to integrated systems, giving users complete visibility into data flows across their entire ecosystem.

iPaaS.com operates using a hub-and-spoke architecture. New data is pulled into a standardized data model, stored in the iPaaS.com database, and then distributed to connected systems that are configured to receive updates.

Data transfer direction in iPaaS.com is defined as:

iPaaS.com uses a queue-based system that holds data awaiting updates and processes events using first-in, first-out (FIFO) methodology. This approach prevents system overload and ensures stable performance for both iPaaS.com and connected systems.

iPaaS.com is built around webhook functionality. The platform uses external systems' APIs to enable or disable webhooks. When webhooks trigger, iPaaS.com captures the ID and method from the webhook payload to queue the appropriate CRUD (Create, Read, Update, Delete) operation.

iPaaS.com can poll external systems on scheduled intervals to retrieve new or updated data. When a record is updated through polling, any connected system configured to listen for changes to that data type will have the updates queued in their outbound queue.

Template mapping allows you to define how data fields in iPaaS.com correspond to specific fields in external systems. These mappings are organized into Mapping Collections, which are grouped by:

Integration Presets are configurable field sets that can be reused across integrations. They are commonly used for:

Template mappings ship with your integration as defaults; subscriber mappings are configured per subscription. Both are organized into Mapping Collections. (references: Data Mapping and Custom Transformation Functions, Data Domains & Mapping Collection Types)

Independent (stand-alone) records exist on their own; child records depend on a parent and move with it. This drives which CRUD flows are available. (references: Supported Flows)

Extend the canonical data model per module when a system has fields the standard model does not cover. (references: Custom Fields)

Each integration is versioned. Subscribers run a specific version, and you ship changes as new versions. Version custom fields store version-scoped configuration.

Reusable transformation logic applied inside mappings to reshape values as they move. (reference: Data Mapping and Custom Transformation Functions)

Reference/lookup tables your integration defines for value translation and configuration.

Manage value-to-value translations (for example, status or unit codes) between iPaaS.com and an external system.

Integrations are compiled .NET assemblies (.dll files) uploaded to a version. The compiled .dll must be under 10 MB. (references: SDK Release Notes & Version History; SDK/Base Development)

Build and test in staging; certified builds are promoted to production. (reference: Move Integration: Data Reference)

Before a Marketplace listing, iPaaS.com reviews functionality, code quality, conventions, marketing, and documentation. (reference: QA and Certification)

Naming and technical standards your integration must follow.