Terminology and acronyms

Connections are used to store credentials, along with other access information for an application or system. Currently integrator.io supports the following connection types.

• NetSuite
• REST API
• SFTP/FTP

For more information on connections, see Connections.

integrator.io supports over 150 connectors, including universal and database connectors, as well as webhooks.

To view all of our connectors, see connector solutions.

Electronic Data Interchange (EDI) is a standardized format used for the digital exchange of business information. integrator.io supports converting between ISA EDI or fixed-width files and JSON files. 

Enterprise Service Bus

Extract Transform Load (ETL) is the process of extracting, transforming, and loading data in a database. It is also often used to retrieve data from external data storage or transmission sources. Legacy ETL technologies were designed to move large batches of structure data (rows and columns). While this strategy is optimal for initial migrations and periodic data loading requirements, some integrations require both real time and batch transfers. Modern cloud integration platforms go beyond data loading and point-to-point use cases with event-based orchestration and big data integration bulk loading and data transformation for analytics. An on-premise enterprise service bus (ESB) or single-tenant hosted versions of a legacy vendors of on-prem software typically communicate only via XML and SOAP. Modern cloud integration technologies can work with these formats and protocols and are designed to take advantage of JSON and REST. Celigo supports Extract (Export flow), Transform (Field mapping transformation UI) and Load (Import Flow and Data Loader).

Exports are used to extract data from an application or system. Exports can run standalone, or in the context of a Flow.

Standalone exports are useful for integrations where user actions (like clicking a button) need to invoke an external application's API in real time and return the results immediately. Standalone exports are especially useful for applications that integrate with more than one application when the development environment is inconveniently designed and writing native API client code would be counterproductive. Celigo uses standalone exports extensively for spreadsheet and email synchronization.

Exports running in the context of a flow execute asynchronously. The data is broken into one or more pages, and integrator.io uses those pages to pass data into the one or more imports. For more information, see Exports.

A flow is a stream of data between two or more systems or applications. A flow exports the data from one or more systems, processes the data according to user-defined settings, and imports the processed data into another system. For more information, see Flows.

Our integrator.io REST API supports the following custom HTTP headers:

• Integrator-Relative-URI
• Integrator-Record-Type
• Integrator-Passthrough

Imports insert data into a destination application. Imports can run standalone or in the context of a flow.

Standalone imports are useful for integrations where user actions (like clicking a button) need to invoke an application's API in real time and return the results immediately. Standalone imports are especially useful for applications that integrate with multiple other applications or applications with inconveniently designed development environments and writing native API client code would be counterproductive. Celigo uses standalone imports for spreadsheet and email synchronization.

Imports running in the context of a flow execute synchronously, but the results return back to the flow for statistical reporting in a job record.

An integration is one or more flows set up to achieve your needs for manipulating and moving data between systems. An integration can refer to a single flow or a set of flows grouped together in a folder. The folder that contains the flow(s) is an integration and is represented by a rectangular tile on the Home page. You can group flows into integrations however you like. Click the integration tile to manage and monitor the flows within the integration.

Integration apps represent fully functional pre-built integrations that any user can install into their integrator.io account from our integrator.io marketplace. They include an installer, an uninstaller, and a settings interface. Developers can push updates at any time for any connector to their entire install base. Integration apps are mostly made up of code (that uses the integrator.io API to interact with a user's account). You can use an integration app to create any number of components in a user's account. All components created in a user's account are tagged with the integration app's _id (via the _connectorId field). An integration app can only modify components tagged with its own _id. The schema primarily serves the purpose of listing an integration app in the integrator.io marketplace (i.e. description, imageURL, websiteURL, etc...).

Integrator.io is an API first platform. Features are released in the API first, and then shortly after in the UI. Our integrator.io API is RESTful, uses JSON, and is secured by Bearer Tokens. The target audience for the API is developers building integration-based apps. Complementing the API, integrator.io supports a rich extension framework. The integrations you build can include an installer, settings pages, and any number of hooks or wrappers (hooks and wrappers give you the ability to write your own custom code, and are useful for requirements that cannot be implemented via configuration alone). Any integrations that you build can be listed in the integrator.io marketplace for easy installation by any other user.

Wrapper is a mechanism for any developer to build your own API and plug imports or exports to the IO platform. This allows you to do custom transformations and connect to systems that do not have direct adapters. This is also our answer to on-premise application integrations.

Hooks are custom code that can run at different stages during the execution of a flow to modify the behavior of export and import processes. Hooks can be run during the export or import stages, including preSave, postResponse, preMap, postMap, postSubmit, and postAggregate.

If you are using NetSuite exports, you can also execute these SuiteScript hooks during your data flow. SuiteScript hooks are run entirely in NetSuite.

For more information on hooks, see Hooks for integrator.io.

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. JSON is a text format that is completely language independent. JSON is an ideal data-interchange language. Learn more: http://www.json.org/

Lookups allow you to find deeper levels of information for a record, and transfer that information later in the flow.

For example, if you export 10 Shopify customers to NetSuite, for each of those records, you can lookup transaction data for the customer (based on a saved search), and add that data to the original export data. Once the lookup step does this, you can use this data later in the flow, once you make a response mapping that includes all the data you just found with the saved search. For more information, see HTTP Import: Static and dynamic lookups.

If you are using integrator.io to build NetSuite-based integrations, we highly recommend you install our Distributed Adaptor (DA for short). It's a SuiteApp that gets installed as a Bundle directly in your NetSuite account. Once installed, it enables a super rich import engine that can be used to map and load NetSuite data in very creative (and efficient) ways.

Differences between NetSuite Distributed and Non-Distributed Imports

1. field ids are all lowercase in the distributed adaptor vs. camel case in non-distributed adaptor.
2. expressions are not yet supported in non-distributed adaptor.
3. customFieldMetadata is required in the non-distributed adaptor.
4. hooks in the distributed adaptor are implemented in SuiteScript vs. node.js in the non-distributed adaptor.

If installing the Distributed Adaptor in your NetSuite account is not an option, you can still create NetSuite imports that use NetSuite's web services API. The capabilities are slightly more limited and the performance can also be slower depending on the complexity of your imports, especially related to the number of dynamic internal id lookups each record in NetSuite will require before import.

Using the web services API enables you to get started immediately without involving a NetSuite admin to to install anything right away.

Differences between NetSuite Distributed and Non-Distributed Imports

1. field ids are all lowercase in the distributed adaptor vs. camel case in non-distributed adaptor.
2. expressions are not yet supported in non-distributed adaptor.
3. customFieldMetadata is required in the non-distributed adaptor.
4. hooks in distributed adaptor are implemented in SuiteScript vs. node.js in non-distributed adaptor.

You may want to take the ID of the submission response and use this ID to reference another record. Customers and Orders. Call other data flows from one flow. E.g. check if the customer exists before inserting an order. If it doesn't exist, insert Customer first and then insert Order.

A Webhook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST.IO is capable of receiving events from any application which supports webhooks. IO Supports Webhook Adaptor Exports.

integrator.io also supports the ability to integrate with any JSON based webhook. An export record is used to register a listener that can then be posted to. IO supports the following webhooks:

• github
• shopify
• travis
• slack
• dropbox
• helpscout
• errorception
• box
• stripe
• aha
• jira
• pagerduty
• postmark
• mailchimp
• intercom
• activecampaign
• segment

In addition, we support custom webhooks that a user can configure via our UI. Learn more: https://webhooks.pbworks.com/w/page/13385124/FrontPage