Comparisons
Boomi alternative: a store and ERP integration on current APIs, run for you
Boomi is an enterprise integration platform with hosted or self-hosted runtimes, connectors for Shopify and NetSuite, and B2B/EDI management. Your team or a partner builds and maintains the processes. A custom integration from us is built for one store and one ERP on the APIs those vendors support today, then hosted, monitored and changed by us.
What Boomi does well
Boomi's Enterprise Platform covers integration, API management, master data (Data Hub), B2B/EDI management and event streams on one account. Integration processes run on a runtime of your choice. Boomi hosts runtime clouds in the Americas, Europe and Asia-Pacific in three forms: a multi-tenant Public Cloud, a single-tenant Dedicated Cloud with VPN, and a Managed Cloud with custom sizing. A basic runtime or a runtime cluster can also run on your own servers, which lets a process reach an on-premises database or ERP behind the firewall.
For a Shopify and NetSuite setup Boomi has three connectors. The NetSuite connector exposes every standard and custom record type, groups large inserts and updates into batches, and pools connections so that two processes on one runtime do not exceed NetSuite's concurrency limit. The newer NetSuite REST connector works on NetSuite's record API (/services/rest/record/v1) with Create, Query, Update, Upsert on an external ID, Delete and Execute SuiteQL. The Shopify connector covers customers, orders, fulfillment orders, products, variants, inventory items, inventory levels, locations and refunds.
B2B/EDI Management handles trading partner profiles and X12 documents over AS2, SFTP and other communication methods on the same platform. Failed documents can be rerun automatically by a retry schedule with a maximum number of retries. Statements about Boomi on this page come from help.boomi.com, read on October 3, 2026.
What a Boomi project asks of your team
Boomi is a platform, so the integration is built inside it: processes, connection and operation components, request and response profiles, and maps between them. Boomi's documentation is explicit about the upkeep that follows:
- Licenses per connection and runtime. Boomi counts one connection license per unique connection per runtime. Its own table: a process with 2 connections on one basic runtime needs 2 licenses; on two basic runtimes, 4; a test copy with new connection components adds 2 more. A deployment without enough licenses does not finish.
- Re-importing NetSuite records. The NetSuite operation caches the record's metadata. When someone adds or renames a custom field in NetSuite, the record has to be re-imported in Boomi before the field moves.
- Concurrency across nodes. Connection pooling does not span JVMs, so it does not cover runtime cluster nodes or forked executions on a runtime cloud. Boomi advises staggering NetSuite processes or running them one after another there.
- History. Logs and processed documents on a runtime are purged after 30 days by default. Longer history needs archiving set up separately.
None of this is unusual for an enterprise platform. It means someone on your side, or a partner, owns the processes, the licenses and the profile updates for as long as they run.
Where the documented limits are
The limits that matter most for a Shopify and NetSuite store are the API versions under the two connectors:
| Area | What the documentation states |
|---|---|
| Shopify API | Boomi's Shopify changelog states the object profiles use Shopify's REST API version 2024-04. Shopify made its REST Admin API legacy on October 1, 2024 |
| Shopify versions | Shopify supports each version for at least 12 months. A request for a version that is no longer accessible is answered by the oldest accessible version, 2026-01 in October 2026 |
| Variants | Shopify's REST product resource allows 3 options and 100 variants per product; GraphQL allows 2,048 variants by default |
| NetSuite SOAP | The original connector uses SuiteTalk SOAP; Boomi lists 2024.2 as the selectable version and certifies on 2025.1. Oracle: 2025.2 is the last SOAP endpoint, no new SOAP integrations from 2027.1, all SOAP endpoints off in 2028.2 |
| NetSuite REST errors | The REST connector maps 4xx responses to Application Error and 5xx to Failure |
| Retries | A retry schedule reruns all failed documents, including those from past executions. On a Boomi runtime cloud, clearing failed documents you do not want rerun goes through Boomi Support |
| Runtime cloud | Boomi limits the number of simultaneous process executions per account on its runtime clouds; no number is published |
The version gap has a practical effect. A profile built on 2024-04 holds the fields as they were then, while Shopify now answers those requests with 2026-01: fields added since are not in the profile, and fields deprecated since can be gone from the response. Features that exist only in GraphQL, such as more than 100 variants on one product, are out of reach of a REST connector. A boot sold in 13 sizes, 2 widths and 4 colors is 13 x 2 x 4 = 104 variants: one product in GraphQL, too many for one REST product.
On the NetSuite side, a process built today on the SOAP connector has a fixed end date. Moving it to the REST connector means new operations, new profiles and new maps, which is a rebuild of that process rather than a setting.
What a custom integration does differently
We build the integration to your systems and your rules, then host and run it. Point by point against the table above:
| Area | Custom integration, hosted and run |
|---|---|
| Shopify API | GraphQL Admin API on a current stable version, moved forward when Shopify releases a new one each quarter |
| Variants | Products and variants written through GraphQL, up to Shopify's 2,048 per product; see variants |
| NetSuite API | REST web services and SuiteQL with OAuth 2.0, RESTlets where a record needs a shaped write; no SOAP |
| Concurrency | One queue per NetSuite account, sized to its concurrency limit of 5, 15 or 20 plus 10 per SuiteCloud Plus license |
| Failures | Temporary errors retried with growing pauses; a data error goes to the dashboard with the reason and the original payload |
| New custom field | Added to the mapping by us when you tell us, or when a run reports it |
Throughput follows from the API choice. Reading 20,000 Shopify variants with a GraphQL bulk query is one operation that returns a file; the same read on REST returns at most 250 variants per page, 20,000 / 250 = 80 requests, each counted against Shopify's rate limit. Orders arrive by webhook in a queue, and a nightly comparison catches any order that did not.
Before go-live the integration runs as a dry run with approval, and after that every run has a log and a diff. The Shopify and NetSuite specifics are on Shopify NetSuite integration, the order flow as a whole on ecommerce ERP integration.
Moving off Boomi
The switch goes one flow at a time. The new integration first runs next to the Boomi process with writes disabled: it reads the same orders, items and stock, computes what it would write, and the result is compared per record with what Boomi wrote. On a runtime with default settings, Process Reporting keeps processed documents for 30 days, which is the window to compare against.
The Boomi maps and profiles are the most complete description of what the old integration does, including the custom fields and the lookups. They serve as the checklist for the new mapping. When a record type matches, the Boomi process for it is turned off in the same step as the new flow goes live, so each record type has one owner. Processes that stay, such as EDI with trading partners, keep their runtime and their licenses. The general method is in replacing an integration, and the wider comparison in custom integration vs iPaaS.
Tell us which Boomi processes carry your store data, and you get a fixed price for the integration that takes them over.
Frequently asked questions
Is SyncMyShop an integration platform like Boomi?
No. Boomi is a platform on which your team or a partner builds processes, connections and maps, and runs them on a Boomi runtime. We build one integration for your store and your ERP with your rules, then host it, monitor it and change it when Shopify or NetSuite changes an API. You get a dashboard with logs, a dry run before go-live and a diff per run, not a process builder.
Does Boomi's NetSuite connector stop working when NetSuite turns off SOAP?
Boomi's original NetSuite connector uses SuiteTalk SOAP web services. Oracle's timeline makes 2025.2 the last SOAP endpoint, allows no new SOAP integrations from 2027.1 and switches all SOAP endpoints off in 2028.2. Boomi also offers a separate NetSuite REST connector, so processes on the SOAP connector need to be rebuilt on the REST connector before then.
Can we keep Boomi for EDI and move the store flows?
Yes. A common split keeps the trading partner setup and X12 documents in Boomi B2B/EDI Management and moves the Shopify and NetSuite flows. The rule is one owner per record type: if Boomi writes sales orders from EDI and the custom integration writes sales orders from Shopify, both use external IDs from different sources so neither overwrites the other. Our EDI integration page covers EDI into the ERP directly.
How many connection licenses does a Shopify and NetSuite process use in Boomi?
Boomi counts one license per unique connection per runtime. A process with a Shopify and a NetSuite connection on one basic runtime uses 2. The same process on two basic runtimes uses 4, and a test copy with new connection components counts again. A custom integration from us has no count of connections, flows or transactions.
What happens to products with more than 100 variants?
Shopify's REST product resource allows at most 100 variants per product, and Boomi's Shopify connector works on the REST API. The GraphQL Admin API allows 2,048 variants per product by default. A custom integration writes products through GraphQL, so a boot in 13 sizes, 2 widths and 4 colors, 104 variants, stays one product.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase