What is the actual difference between a native connector and middleware?
A A native connector is integration software published by the ERP or platform vendor themselves, configured rather than built. Acumatica ships native connectors for Shopify and BigCommerce. is integration software published by the vendor and configured rather than built. For Acumatica that means the commerce connectors Acumatica lists on its own site: Amazon, Shopify and BigCommerce, described as synchronizing product data, inventory, pricing, customers and orders. You switch entities on, you map fields, and you put Prepare and Process on a schedule. There is no code and no server.
Middleware is a layer of software that sits between the ERP and the storefront, translating and enforcing rules that neither system holds on its own. It can be a hosted integration platform or a custom service. is a layer you own that sits between Acumatica and the storefront, translating and enforcing rules that neither system holds on its own. It can be a hosted integration platform, a small service your team runs, or a set of functions behind an API. The defining property is not the technology, it is that a rule lives somewhere you control.
The distinction that matters is not "configured versus coded", it is where a decision gets made. A connector copies values that already exist. Middleware answers questions. "What does this customer pay for this item today" is a question, not a value, and no amount of connector configuration turns it into one.
Deciding The source of truth is the system that gets to be right when two systems disagree. For price, stock and customer terms in an ERP-run business, that is almost always the ERP. field by field is the work that makes this choice obvious. Once you have written down which system wins for price, for stock, for the customer record and for the order, you usually already know whether the native connector can carry it.
Checked against: Acumatica commerce connectors page, read 20 August 2026, Acumatica community 11823: Prepare and Process the Price List entity on a schedule
What can each layer actually do for an Acumatica seller?
One claim per cell, and every claim in the native connector column is either from Acumatica documentation or from a named Acumatica community thread read on 20 August 2026. The middleware column describes the general mechanism, because what middleware does depends on what you build into it.
Read the last two rows before the first four. Most integration regret is about operations rather than about features.
| Criterion | Native Acumatica connector | Middleware you own |
|---|---|---|
| Who publishes and maintains it | Acumatica. It ships with the product, it is documented by Acumatica, and it changes when Acumatica ships a release. | You, or your partner. It changes when you decide, which is both the benefit and the bill. |
| Contract pricingThis is the row that moves most Acumatica B2B projects off the native-only path, and it moves them for a business reason rather than a technical one. | Default Price and price lists. Community 17608: "No. Only Default Price is supported" when asked about the effective sales price. | Can resolve the effective price per customer at runtime, including prices from a released Sales Price Worksheet, and cache it. |
| Availability per buyerAcumatica’s Commerce Edition team lead recommended exactly this rule as a customization in community thread 5378, using ship-to state as the example. | Warehouse quantities exported to storefront locations. No rule that says this buyer sees this warehouse. | Can apply the rule, from the customer record, the ship-to, or geography, and can publish a buyer-scoped number. |
| Credit before checkout | Credit verification happens in Acumatica when the order lands. Acumatica’s Shopify B2B datasheet describes placing risky orders on hold. | Can ask Acumatica for the live position while the buyer is still on the page, and can decide what to show when Acumatica does not answer. |
| Failure behaviourA connector that fails a whole batch for one bad row is survivable at 200 items and a real operational cost at 40,000. | Entity-level. A Shopify price list sync fails with "Sync ID is not found for the record" when a single stock item on the list has not synced. | Whatever you build: per-record retries, dead letter queues, alerting to a human, and a replay when the ERP comes back. |
| What a release does to it | Acumatica revises connector behaviour by release. The 25R1 template sync change began rejecting attributes with duplicate option descriptions. | Insulated from platform changes you did not make, and exposed to API changes at both ends, which you find out about by testing. |
| Who fixes it when it stops at 2amIf you cannot name the person who owns middleware at 2am, you are not ready to own middleware. | Your VAR, through Acumatica support, on Acumatica’s terms. You have a vendor to escalate to and limited ability to work around it. | Your team or your partner, on your terms. Faster, and only if someone is genuinely on the hook by name. |
| Cost shape | Low to start, and effectively fixed. Configuration, mapping and testing, then licence and upgrades. | Higher to start, and ongoing. Build, host, monitor, and re-test at both ends every time either system changes. |
Checked against: Acumatica community 17608: only Default Price syncs, Acumatica community 22606: "Sync ID is not found for the record" on price list sync, Acumatica community 5378: warehouse routing as a customization, Acumatica community 30860: 25R1 template sync validation change, Acumatica Shopify B2B Connector datasheet, dated 23 September 2025
At what point does the native connector stop being cheap?
At the first customization, and the reason is arithmetic rather than engineering. A connector customization is not a one-off cost. It is a cost you pay again at every Acumatica release, because the thing you extended is a component Acumatica revises and does not owe you a stable interface for. Two customizations means two of those, forever, and nobody puts that line in the business case.
The pattern we see is not a decision, it is a drift. A team buys the native connector because the demo was honest and the fit was close. Then the pricing gap appears, so somebody writes a nightly job. Then availability needs a rule, so somebody writes another. Then a release changes a validation rule and the two jobs need re-testing by a person who has left. At that point the business owns middleware without ever having decided to, and owns it in the worst possible shape: several scripts, no monitoring, and no name against it.
The honest version of the decision is this. Middleware is not more expensive than a customized native connector. It is more expensive than an uncustomized one. So the real question is whether you can genuinely stay uncustomized, and the five triggers below are how you find out before you sign rather than in month four.
Your published prices come from released Sales Price Worksheets rather than from the stock item Default Price, and buyers have to see them. Acumatica community 17608 is the whole argument in one sentence.
A buyer has to see a warehouse-specific number. Acumatica’s own answer to this in community 5378 is a customization, which is the first script in the drift.
Credit has to be checked before the buyer is told the order is accepted, rather than after it lands in Acumatica.
Something outside the connector’s entity list has to move: open invoices, serial or lot data, freight rules, a customer-specific part number.
You are running more than one storefront, or a storefront plus a marketplace, and the same rule has to be true in both. Two connectors with the same logic configured twice is a bug factory.
Checked against: Acumatica community 17608: only Default Price is supported, Acumatica community 5378: per-buyer warehouse as a customization, Acumatica community 30860: a release changing connector validation behaviour
When is middleware the wrong answer?
More often than integrators like to say. Middleware that only forwards records is pure overhead: you have added a system, a deployment, a monitoring surface and a person, and bought nothing that the native connector was not already doing for free. If you cannot name the rule the middleware exists to enforce, it does not need to exist.
It is also wrong when the honest fix is smaller. A distributor with 40 contract accounts and 12,000 items does not necessarily need runtime pricing. They may need to sell a subset of the catalogue online at list, keep the 40 accounts on the phone or on EDI for another year, and revisit it once the channel has earned the investment. Scoping the problem out is a legitimate architecture, and it is the one option a vendor never proposes.
And it is wrong when nobody will own it. Middleware without monitoring is worse than no middleware, because a silent failure in a layer nobody watches produces wrong prices rather than error messages, and wrong prices are found by customers. Before you commit, get a name against three things: who deploys it, who is paged when it stops, and who re-tests it after an Acumatica release.
One more case, less obvious. If your platform can already do the thing at runtime, middleware may be the wrong layer rather than the wrong idea. Drupal Commerce resolves a price through a chain of price resolvers that receive the customer, the store and the time, so a custom resolver can go and ask Acumatica directly. Shopware is extendable in the same spirit. On those platforms the logic can live in the storefront rather than in a third system, which is fewer moving parts for the same outcome.
Checked against: Drupal Commerce developer guide: price resolvers and the pricing Context, Shopware developer docs: B2B Components introduction
Is iPaaS a third option, or the same option with a licence?
Mostly the same option with a licence, and that is not an insult. An integration platform such as Celigo, Boomi or Workato is middleware where somebody else owns the runtime, the retries, the logging and the connectors to each end. You still write the rule. You still own the mapping. What you buy is the operational scaffolding, which is the part most mid-market teams underestimate and the part that decides whether a failure is noticed.
The pattern shows up in the Acumatica community in exactly this shape. In thread 5378, one contributor suggested an iPaaS reading Acumatica’s OData INSiteStatus feed into BigCommerce custom fields to get per-warehouse numbers onto the page. That is a rule, running outside both systems, deployed on somebody else’s runtime. It is also worth knowing what it is not: values in custom fields are content, so the platform will not use them to prevent an oversell.
We are not going to rank the iPaaS vendors here, because we do not have comparable first-hand data across them and a ranking without that is guesswork dressed up. What we can give you are the questions that separate them for an Acumatica B2B use case, and they are not the questions the sales engineer will lead with.
Does it have a real Acumatica connector, or a generic REST connector and a promise? Ask which Acumatica endpoints it uses and whether it handles the contract-based API version.
What happens to a record that fails? Ask to see the error queue, the retry policy and the replay, not the happy-path demo.
How is it licensed as volume grows: by connection, by flow, by record? A pricing model priced per record gets expensive precisely when the channel starts working.
Can it answer a question synchronously, or only move records on a schedule? A tool that cannot serve a price during a page render is not a runtime pricing solution.
Who at your company can change a flow, and what happens when that person leaves? A low-code tool that only one person understands is a custom build with better branding.
Checked against: Acumatica community 5378: an iPaaS reading OData INSiteStatus into storefront custom fields
How do you decide this before you commit?
Write down the rules first, then choose the layer. Every project we see that regretted its architecture chose the layer first and discovered the rules afterwards.
The test below takes a day and it is deliberately unglamorous. If every rule you write down is a copy, buy the native connector and spend the money on merchandising. If two or more are questions, price middleware into the business case now, while it is still a line item rather than an emergency.
List every field the storefront needs from Acumatica. Beside each one write copy or question. A copy moves a stored value. A question needs an answer computed for a customer, a quantity or a moment.
For each question, write who is allowed to be wrong and for how long. A stock figure that is five minutes stale is usually fine. A price that is one day stale is usually not.
Check whether the native connector already carries each copy. Prices, availability, customers and orders are documented; anything outside that entity list is yours either way.
Cost the questions twice: once as a connector customization re-tested every Acumatica release, once as middleware with monitoring. Compare over three years, not one.
Decide the source of truth per field and put it in writing, then hold the integrator to it. Most integration arguments are an unresolved source-of-truth question wearing a technical costume.
Name the owner. If no name appears in step six, the answer is the native connector and a smaller scope.
Checked against: Acumatica commerce connectors: the entities the native connectors carry
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- Can the native Acumatica connector handle customer-specific pricing on its own?
- Not the effective price Acumatica would calculate at order entry. Acumatica community thread 17608 answers a direct question about syncing the current effective sales price with "No. Only Default Price is supported". Per-customer prices can still reach a storefront as price lists or Shopify B2B catalogues, prepared and processed on a schedule, which works when your pricing fits a small number of bands and does not when your prices come from released Sales Price Worksheets.
- How much does middleware cost compared with the native connector?
- We will not quote a number, because the honest answer depends on how many rules you are enforcing and who operates it, and a made-up range would be worse than no range. The structural difference is that the native connector is mostly a fixed cost and middleware is mostly a recurring one. The comparison that matters is middleware against a customized connector, not against an uncustomized one, because a connector customization is re-tested at every Acumatica release.
- Is an iPaaS such as Celigo or Boomi different from custom middleware?
- Operationally yes, architecturally no. An iPaaS is middleware where the vendor owns the runtime, the retries, the logging and the endpoint connectors, and you still own the rules and the mappings. The questions that separate iPaaS options for Acumatica B2B are whether the Acumatica connector is real or generic, what happens to a failed record, whether it can answer a request synchronously during a page render, and how the licence scales with volume.
- What is the first sign that we have outgrown the native connector?
- Somebody writes a script. The moment a scheduled job, a generic inquiry export or a push notification appears alongside the connector to fix a gap, you have started building middleware without deciding to. That is the point to stop and decide deliberately, because the failure mode is not one script, it is four scripts with no monitoring and no owner, discovered when a customer notices a wrong price.
- Can we avoid middleware by choosing a different platform instead?
- Sometimes, and it is worth checking before you buy a layer. Drupal Commerce resolves prices through a chain of price resolvers that receive the customer, the store and the time, so a custom resolver can ask Acumatica directly and the logic lives in the storefront. Shopware is extendable in the same way. That removes a system rather than a cost, since you still write and maintain the rule, but fewer moving parts is a real benefit when your team is small.
- Does Acumatica 2026 R1 change any of this?
- It changes what the native connector covers, not the shape of the decision. Acumatica’s 2026 R1 page lists importing BigCommerce companies for B2B commerce, including company accounts, additional B2B customer details and orders, plus Acumatica Payments for Shopify and BigCommerce. More entities in the native connector means fewer copies you have to build. It does not turn a question into a copy, so the pricing and availability rules above still need a home.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.