Adjusting throttle settings controls both the quantity and frequency of API calls. Syncing a single data element may require hundreds of calls, depending on the data structure's complexity. For example, when iPaaS.com synchronizes a variant, it must process the parent product, options, option values, variant products, categories, and inventory for each location.
When to Use API Throttling
Throttling API calls is particularly valuable when working with systems that have inherent limitations:
External Systems Limitations
Older, on-premises systems may crash under high call volumes.
Systems with built-in API call restrictions based on:
Your subscription plan
Plans that charge surcharges for exceeding call limits
Throttling Benefits
For systems with restrictions, properly throttling your calls prevents error messages and costly retries. Consider a transaction requiring 10 API calls to complete. If you hit a limit after 9 calls:
The entire transaction fails.
All 9 previous calls are wasted.
The complete process must restart from the beginning.
Properly configured throttling ensures transactions complete without exceeding system limitations, improving overall efficiency and reducing your operational costs.
Configuring API Throttling Settings
iPaaS.com provides throttling controls for each integration that you can configure through each integration’s subscription settings.
Navigate to Subscription Management > Subscriptions.
On the Subscriptions page, find your target integration.
Click the Edit button for that specific integration.
Configure the throttling settings as needed.
These throttling settings apply only to the selected integration and help you manage outbound API calls according to the external system's limitations.
Default Values
Each integration comes with a set of default values established by iPaaS.com. You can adjust these parameters to suit your specific requirements.
How it Works
The throttle limits use the API Throttle Limit and API Throttle Seconds fields to establish their rate. For example, if your integration has these settings:
You would have 500 calls every 60 seconds.
You can throttle both TO and FROM iPaaS.com flows.
Concurrent Connections
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:
High concurrent connections = fire hose (intense burst)
Low concurrent connections = garden hose (steady flow)
Both may deliver the same total volume, but the fire hose approach can overwhelm your garden.
Example: A small, on-premises 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.
NOTE: Lowering the number of Concurrent Connections is more effective than setting the Throttle Limits.
Concurrent Batch Executions
Some integrations allow for repetitive calls to be grouped into a “batch” to increase performance. This setting defines the size of that batch.
For example, inventory updates for Magento require a separate call for each Source update. If there are 100 Sources, making 100 sequential calls can take considerable time. Setting the batch size to 10 allows us to make 10 calls in parallel before waiting for results, speeding up the overall process.
However, there are tradeoffs:
Each batch is treated as one connection for the Concurrent Connections setting, though in reality, each call in the batch is a concurrent connection, potentially overriding that setting
Each batch is treated as a single connection for error reporting, making error messages less reliable
If you encounter errors related to batch updates, reducing the batch size to 1 may provide more precise error messages. Always adjust this setting while monitoring for performance issues related to too many concurrent connections.