Adjusting throttle settings changes how many API calls and how often those calls are made. Please note that syncing a piece of data could take several hundred calls, depending on the complexity of that data structure. For instance, with a variant, iPaaS.com pulls in or pushes out the parent product, options, option values, variant products, categories, inventory (for each location), etc.

Throttling API calls is particularly valuable when dealing with systems that have limitations.

Older, on-prem systems are vulnerable to crashing under high call volumes.

For these restrictive systems, properly throttling your calls helps prevent error messages and costly retries. For example, if a transaction requires 10 API calls to complete, hitting a limit after 9 calls means:

Properly configured throttling ensures transactions can complete without exceeding system limitations, improving efficiency and reducing costs.

iPaaS.com provides throttling controls for each integration that you can configure through each integration’s subscription settings.

These throttling settings apply only to the selected integration and help you manage outbound API calls according to the external system's limitations.

Each integration has a set of default values set by iPaaS.com. You are free to adjust these to your needs.

The throttle limits use the limit and seconds fields to create their rate. If this was the settings in the integration:
​

You would have 500 calls every 60 seconds.

You can throttle both TO and FROM iPaaS.com flows.

Concurrent connections control how many simultaneous API requests we make to the external system. Adjusting concurrent connections is more effective than setting throttle limits.

Think of it like water flow:

Both may deliver the same total volume, but the fire hose approach can overwhelm your garden.

Example: A small, on-prem server might comfortably handle 500 requests per minute, but 50 concurrent connections would send 50 requests in the first second, potentially causing a crash. It's better to spread those 500 requests evenly across the minute.

Avoiding Wasted Calls: With complex transfers requiring multiple calls (e.g., 10 calls per transfer), throttle limits can cause incomplete transfers. If you hit your 500/minute limit with 20 concurrent connections, you could waste up to 180 calls per minute when transfers are interrupted mid-process.

Recommendation: For most systems, set the Throttle Limit to 0 (unlimited) and control flow using concurrent connections. This creates a smooth, constant flow rather than a disruptive start/stop pattern.

This controls how many simultaneous connections we will have to the external system’s API.

Some integrations allow for repetitive calls to be grouped into a “batch” to increase performance. This setting defines the size of that batch. An example is inventory updates for Magento. A separate call for each Source update is required, so if there are 100 Sources, making 100 calls one after the other can take some time. Setting the batch size to 10 will allow us to make 10 calls in parallel before waiting for the results, which can speed up the overall process. There are tradeoffs here, though, as the batch is treated as one connection for the Concurrent Connections setting above when, in actuality, each call in the batch is a concurrent connection, thus overriding that setting in some scenarios. Thus, it is best to always adjust this setting keeping an eye out for performance issues that seem to be related to too many concurrent connections. Each batch is also treated as a single connection for error reporting purposes, making error messages less reliable. If errors related to something updated in a batch are encountered, reducing the batch size to 1 may result in a better error message.