This guide is intended for Managed Integration Service Providers (MiSPs) or technical users familiar with making API calls and using Postman.
Background
This document outlines a method for synchronizing large datasets—either pushing data to iPaaS.com or pulling data from iPaaS.com—by leveraging the Postman Runner feature. This technique is particularly useful when seeding an entire product catalog, moving historical orders, or handling datasets exceeding the standard limits of the manual sync interface.
Understanding the Standard iPaaS.com Sync Process
Typically, iPaaS.com processes data synchronization as follows:
Webhook Notification: For incoming data, a webhook notifies iPaaS.com about new or updated records in the source system.
Queue Entry: The webhook triggers the creation of an entry in a processing queue.
Data Retrieval & Normalization: As the entry reaches the front of the queue, iPaaS.com makes a GET request to the source system API to retrieve the full record details. Based on the defined scope (e.g.,
CREATE,UPDATE,DELETE) and mapping configurations, the data is normalized into iPaaS.com's data models.Outbound Processing: Once the data is created or updated within iPaaS.com, any connected systems listening for changes to that data type will have the corresponding record queued for outbound synchronization, following a similar process.
Polling Alternative: Systems using polling follow a similar pattern; the polling process identifies new/updated record IDs, which are then added to the processing queue.
Manual Sync: The manual sync page allows users to add records to the queue directly. Using "debug mode" during a manual sync prioritizes the record in the queue and provides additional logging. However, the manual sync page typically has a limit (e.g., 3,000 IDs).
This Postman Runner method essentially automates the process of manually adding many records to the iPaaS.com queue via API calls, bypassing the standard interface limitations.
Before You Begin: Alternative Methods
Consider these alternatives before using the Postman Runner method, as they might be simpler for your specific needs:
Polling with
/pollScope: If you need to import data TO iPaaS.com and the integration uses polling (not all do), you can often trigger a full data pull using the manual sync feature with a/pollscope.NOTE: Many polling integrations store a "last polled date." To ensure all data is captured, you may need to clear this date in the integration settings before initiating the
/pollmanual sync.
Initialization Feature: Check if the specific data type and direction support an "Initialization" feature within iPaaS.com, which is designed for bulk data loading.
Step-by-Step Guide to Using Postman Runner for Bulk Sync
Step 1: Prepare Your Data
To move data TO iPaaS.com (importing into iPaaS.com):
Obtain a complete list of the unique identifiers (IDs) for the records you want to import from the source system. You might get this via an export feature or by querying the source system's API.
NOTE: Ensure these IDs are in the exact external ID format that iPaaS.com expects for this specific integration, as documented in the subscription's documentation.
To move data FROM iPaaS.com (exporting from iPaaS.com):
This updates any systems that are listening. You can turn off FROM webhooks for the other systems to have the same edddect.
In most cases, you do not need to run a separate FROM sync. When you push records TO iPaaS.com, any connected systems listening for outbound changes will automatically be triggered. A separate FROM Postman run is only needed if you want to push to one specific downstream system while intentionally bypassing others (e.g., you've disabled other outbound webhooks).
Use the iPaaS.com API to retrieve the internal iPaaS.com record IDs you need to push. You will likely need to parse these IDs from the JSON API response.
If the data type/direction supports initialization, you can use that feature as well.
Step 2: Identify the Correct Scope
The 'scope' tells iPaaS.com what action to perform (e.g., product/create, customer/update, order/delete).
The supported scopes for your integration and data type are found on the Inbound/Outbound Data Flows page within a subscription's settings or on the Manual Sync page in iPaaS.com.
NOTES:
You must use the exact scope name as it appears in iPaaS.com for that specific integration. Ensure accuracy in spelling and case. You can still get a 200 response from Postman with a wrong scope name.
Be aware that scopes for importing data (TO iPaaS.com), can vary significantly between different integrations. For exports FROM iPaaS.com, scopes are more consistent across integrations.
Step 3: Create Your CSV File
Prepare a CSV file with at least one column,
id.(Optional) Include a second column,
scope. This is useful if you need to perform different actions for different records. If all records use the same scope, you can omit this column and specify the scope directly in your Postman request setup later.
The column headers must match the variable names you use in Postman (e.g., id, scope).
Example CSV:
id,scope
12345,product/create
45671,customer/update
88900,product/create
There are three ways to specify scope:
Hardcode it in the request body: Simplest if all records use the same scope
Set it as a Postman variable with a fixed value: Useful for keeping the body clean and for reuse across different scopes
Include a
scopecolumn in your CSV: Required only if different records need different scopes
You cannot mix TO and FROM scopes in a single Postman Runner run if they require different endpoints.
Step 4: Configuring Postman
Authentication
You need the Webhook API Key associated with the iPaaS.com subscription you are working with. Find this key in iPaaS.com under: Subscription Management > Subscriptions. Find the relevant subscription in the list and click the Edit icon.
This key will be used as a Bearer Token for authentication in your Postman request header (Authorization: Bearer YOUR_API_KEY).
API Call Details
Use the following settings for the API call details.
Method:
POSTURL: You will target the
/v2/ipaasendpoint. The URL depends on the environment:FROM iPaaS.com
Production:
https://api.ipaas.com/hookspi/v2/ipaas
TO iPaaS.com
Body: The request body requires two fields:
id- the record ID (use{{id}}as a Postman variable)scope- the action to perform (can be hardcoded or use{{scope}}as a variable if your CSV includes a scope column)
You do not need to construct a full data payload. The endpoint queues the record for iPaaS.com to retrieve and process. It does not accept the record data directly.
To create a call for a TO/FROM iPaaS.com webhook:
Ensure your
POSTrequest is saved within a Postman collection.Click
File>New Runnertab, or find the Runner button in Postman.Drag the collection containing your prepared API request into the Runner window.
Select the specific request you configured.
Click Select File and upload the CSV file you created in Step 3: Create Your CSV File.
Preview the data to ensure it's parsed correctly.
Ensure the iteration count matches the number of data rows in your CSV.
Double-check that your request includes the correct
Authorizationheader with the Bearer Token (Webhook API Key). If you set authentication at the collection level, it should be inherited.Confirm that the variable names in your request body (
{{id}},{{scope}}) match the headers in your CSV file.(Optional) In Advanced Settings, add a delay between requests (e.g., 100-500 milliseconds). This helps prevent overwhelming the iPaaS.com queue and potentially impacting other processing tasks.
Click Start Run.
Important Considerations
Local Execution: The Postman Runner executes the requests from your local machine. Ensure your computer remains powered on and connected to the internet throughout the entire run.
Test Thoroughly: Always perform a test run with a small batch of IDs (e.g., 5-10 records) first. Verify in iPaaS.com that these records are queued and processed as expected before running your full dataset.
Monitor Queue: Keep an eye on the iPaaS.com events queue during and after the run to ensure records are being processed correctly and to gauge the impact on system performance.
Validation via Queue: Do not rely solely on a
200 OKHTTP status response from Postman to confirm success. The API endpoint is designed for speed and may accept the request (returning200 OK) even if the provided scope is invalid or misspelled for that integration, only failing later during processing. You must validate that the sync operations worked correctly by checking the Events Queue within iPaaS.com after running your test batch and full sync.