The Integrator experience gives you the tools to register an integration, describe it for the Marketplace, manage its versions, and configure how it behaves. This article maps the Integrator UI top to bottom and points to the deep-dive article for each area.
The Integrator dashboard
The dashboard is where you see and manage the integrations your company owns. From here you open an integration to configure it, manage its versions, and edit its Marketplace details. You can switch to a Subscriber view at any time to test your implementation the way a subscriber would experience it. For how the Integrator role differs from Subscriber and MiSP, see iPaaS.com Core Concepts and Terminology.
Registering an integration
Registering creates the integration record for a target system. This is the starting point before you upload a build or configure anything else. You give the integration its name and identify the external system it connects to; the detailed configuration happens per version once the record exists.
Edit and marketing info
The marketing info is what subscribers see when they find your integration in the Marketplace: display name, description, branding/logo, category, and positioning. Complete and accurate details here are part of what certification reviews. For the full pre-publishing checklist of documentation and marketing items, see Integration Documentation and Marketing.
Integration versions
Every integration is versioned. You upload your compiled .dll to a version, configure that version's settings, and publish it for subscribers to use. Subscribers run a specific version, so you ship changes by creating and publishing new versions rather than editing a live one in place.
Version custom fields (Template Custom Fields): values that are the same for all subscribers of a version, such as an application ID used in the external system. They are set in the Integrator portal and are not visible or editable by subscribers. For how these store and behave alongside presets and persistent data, see Configuration and Data Storage.
The build: the compiled
.dllmust be under 10 MB. See the SDK, Integration Template, Sample, and Development Utility article for how the build is produced.
Per-version configuration areas
Once a version exists, you configure how the integration behaves. Each area below has its own reference where noted:
Supported Features: declare which data types, directions, and operations the integration supports, plus external ID formats and endpoints. See Supported Features Format.
Presets and data storage: subscriber-set configuration values, persistent data, and where to store what. See Configuration and Data Storage.
Scopes: define the scopes used to work with the third party's webhooks. See Defining Integration Scopes.
Webhook receiver: configure how inbound webhooks are received and parsed. See Webhooks Integration and Webhook Scopes, Prioritization & the Webhook Receiver.
Template mappings: the default field mappings that ship with the integration. See Data Mapping and Custom Transformation Functions.
Template translation collections: default value-to-value translations shipped with the integration, for example mapping external status codes to iPaaS.com values.
Integration tables: lookup and reference tables the integration defines for value translation and configuration.
From configuration to certification
Once the version is configured and tested in staging, submit it for certification before it can be listed and promoted to production. Certification is covered in the Testing, Deployment & Maintenance section.
