01 / backbone
Fusion is the ledger
Financials, Receivables, Order Management, Pricing, inventory. The authoritative record the business is run on, across legal entities and ledgers.
The real problem
Oracle Fusion runs the business. The store runs the customer.
The work is the space between: financials, receivables, order management, pricing and inventory on one side, B2B buyer self-serve on the other.
02 / front door
Shopify is self-serve
Where B2B buyers place repeat orders without a phone call, a rep, or an EDI batch.
03 / the gap
The middle is where it breaks
Duplicate customers. Orders written twice. Pricing that drifts. Silent failures at month-end close.
Our position
We built a product around that exact gap. NetSuite runs in production on it today. Oracle Fusion Cloud ERP plugs in as a first-class, path-mapped adapter on the same contract.
Before anyone scopes a connector
Which Oracle ERP do you actually run?
"Oracle ERP" is four different products with different data models, APIs, and auth. The connector that fits one will not fit the others. This page is about Oracle Fusion Cloud ERP specifically. Confirm yours before a single line is scoped.
This page subject
Oracle Fusion Cloud ERP
The SaaS suite: Financials Cloud, Receivables, Order Management, Pricing. REST under /fscmRestApi, FBDI and BICC for bulk, OAuth 2.0 via OCI IAM. The product this page maps.
Adjacent Oracle ERP
Oracle NetSuite
A separate cloud ERP with SuiteQL, SuiteTalk, RESTlets and token auth. We run NetSuite middleware in production today. Different surface entirely.
→ see the NetSuite ⇄ Shopify pageAdjacent Oracle ERP
Oracle E-Business Suite
The on-premise / EBS line, integrated through ISG and AIS endpoints with its own pricing internals. Mention it so we route correctly. Not the Fusion surface.
→ confirm before scopingAdjacent Oracle ERP
JD Edwards
EnterpriseOne / World, a distinct platform with its own orchestrator and adapter sets. Different again. Tell us which Oracle you mean.
→ confirm before scopingIf a prospect says "Oracle ERP," we confirm which one before scoping. Everything below is Oracle Fusion Cloud ERP. The NetSuite build is documented on its own page and cross-linked in the footer.
The decision guide
The three ways to connect Oracle Fusion and Shopify, and when each is right.
There are three ways to connect Shopify to Oracle Fusion Cloud ERP. The right method is decided by number of legal entities and ledgers, order-to-cash complexity, and integration throughput, not by price alone.
Option one
OIC + native Shopify adapter
Oracle Integration Cloud, Oracle's own iPaaS, with its native Shopify adapter. Message-volume priced. You still own the orchestration, FBDI templates, callback wiring, and reconciliation.
- pricingOIC by message volume
- ceilingShopify REST · 2 req/sec
- buildassemble it in OIC
Right for single-entity stores with standard order and inventory sync, on teams that own OIC.
Option two
Third-party iPaaS connector
A prebuilt connector or iPaaS such as Celigo, Cleo, Alumio, Commercient, or eZintegrations. Fixed field mappings against Oracle's standard model. The richest prebuilt Shopify content targets NetSuite, so against Fusion it is thinner.
- pricingsubscription
- mappingfixed, standard model
- gapmulti-org and B2B not in box
Right for standard catalogs and order flows that fit the template the connector happens to support.
Option three Makro builds this
Custom middleware
A custom build from a Shopify Plus partner, around your exact order-to-cash flow, owned by you. OIC gives you the pipes. We build the logic that runs through them: routing, B2B pricing, buffered inventory, reconciliation.
- pricingscoped build + support
- mappingyour config, not the standard model
- ownsrouting, dedup, retries, replay
Right for Plus, B2B, multi-currency, and multi-org merchants that have outgrown a fixed-mapping connector.
Choose the OIC native adapter or a prebuilt connector for single-entity stores with standard order and inventory sync. Choose a custom build from a Shopify Plus partner like Makro when multi-legal-entity routing, multi-ledger finance, Shopify B2B, or high throughput against the connector ceiling makes a fixed-mapping connector overspill.
Architecture
One direction for master data. Both directions for orders.
Customers, items, inventory and pricing are read out of Oracle Fusion and pushed to Shopify. The storefront never writes to the ledger. Orders are the only thing that travels both ways.
System of record
Oracle Fusion Cloud ERP
read · never overwritten
The platform
Makro Middleware.
map · reconcile · audit
The storefront
Shopify Plus B2B
where buyers self-serve
Master data: Oracle Fusion → Makro Middleware → Shopify, one way
Orders: Shopify → Oracle Fusion, status returns
Fusion REST APIReal-time, per-record reads and writes under
/fscmRestApi. Query grammar of q / fields / expand, max page size 500, always paginate on hasMore. The default transport for live sync.Oracle ⇄ MKFBDI · bulk inboundFile-Based Data Import for bulk and initial loads. Heavy catalog and customer loads move off per-record REST onto the batch path designed for it, above roughly 100 records.MK → Oracle
BICC · bulk outboundBusiness Intelligence Cloud Connector for large extracts out of Fusion. The high-volume read path when a full master-data set has to leave the ERP at once.Oracle → MK
Business eventsFusion announces a change instead of being polled. FBDI completion fires
ErpImportBulkDataEvent; the platform picks it up, with ESS-job polling as the recovery fallback.Oracle → MKOCI IAM · OAuth 2.0Client-credentials auth against the OCI IAM identity domain. A 1-hour Bearer token, cached and rotated, on a dedicated least-privilege service user. No shared passwords.handshake
salesOrdersForOrderHubOrders captured in Shopify are written into Order Hub, status flows back. A webhook is HMAC-verified, deduplicated by
OrderKey, transformed, and pushed once.Shopify ↕ OracleThe console
This is not a connector. It is something you operate.
Every sync, every failure, every reconciliation is visible. This is the same Makro Middleware console your team would watch in production. Move through the views.
console.makro.agency / meridian-industrial / sync
live
Sync Monitor
Sync Monitor
Dead Letter Queue
Observability
Entity Key Map
Schedules
Order Relations
Records / 24h ▲
48,210
across 9 entities
Queue depth
3 pending
2 retrying · 1 review
Avg latency
1.2s
event → Shopify
Last reconcile
04:00
0 drift detected
Activitylive · last 60s
Throughputrecords / hr
In queue
3
of 48,210 processed
Auto-retrying
2
transient · rate-limit
Needs review
1
permanent
Resolved / 24h
41
38 auto · 3 manual
Dead Letter Queuenothing is dropped in silence
| Time | Entity | Error class | Attempts | Next | Action |
|---|---|---|---|---|---|
| 08:13:04 | order · SHOP-10288 | PERMANENT · validation | 3 / 3 | held | Inspect |
| 07:55:22 | account · 0091-MERIDIAN-W | TRANSIENT · timeout | 2 / 5 | 09:50 | Retry now |
| 06:40:11 | item · ITM-44120 | RATE_LIMIT · 429 | 1 / 5 | paced | Inspect |
Sync volume7-day · records
Circuit breakersper endpoint
Oracle Fusion · RESTlast trip · never
closedShopify · Admin APIlast trip · 3d ago
closedAvalara · AvaTaxlast trip · never
closedUptime · 90 dayserror rate 0.03%
account · Meridian Westentity_key_map
oracle keyPartyNumber 1004182
source refSHOPIFY:cust_88…
shopify gidgid://shopify/Company/61…
checksuma91f… unchanged
versionv17
→ decision: SKIP · already in sync
Every record carries its identities at once: the Oracle internal key, the external Source System Reference, and the Shopify gid. The middleware reads this row before every write and decides create, update, or skip.
Orders are idempotent because of the OrderKey, SourceOrderSystem:SourceTransactionId. Push the Shopify order id and a repeat is rejected as a duplicate, not doubled. Customers de-dupe on the Accounts Source System Reference child.
Change detection runs on the stored checksum, so a catalog of 50,000 items with 12 real edits syncs 12 records, not 50,000.
Active schedules
7
all workflows enabled
Runs today
96
0 failures
Next run
09:46
inventory levels
Nightly batch
01:00
FBDI · 48,210 records
Workflowstenant · meridian
Item delta syncitemsV2 · RESTevery 15 min✓ 09:38 · 142 recordsnext 09:53Run now
Inventory levelsAvailable Quantity Detailsevery 5 min✓ 09:41 · 3 SKUsnext 09:46Run now
Resolved pricingpriceSalesTransactionhourly✓ 09:00 · 1,204 rowsnext 10:00Run now
Accounts & partiesCX accounts · RESTevery 15 min✓ 09:40 · 6 recordsnext 09:55Run now
Order status returnOrder Hub → Shopifyevery 5 min✓ 09:42 · 11 ordersnext 09:47Run now
Full catalog batchFBDI bulk importnightly · 01:00✓ 01:00 · 48,210 recordsnext 01:00Run now
Daily reconciliationboth systems vs key mapdaily · 04:00✓ 04:00 · 0 driftnext 04:00Run now
Shopify order#1042
gidgid://shopify/Order/57…
companyMeridian West
line 1ITM-99320 × 12
line 2ITM-44120 × 4
total$8,420.00
SHOPIFY:1042↔OrderKey✓
cust_88…↔PartyNumber 1004182✓
ITM-99320 × 12↔99320 · qty 12✓
ITM-44120 × 4↔44120 · qty 4✓
$8,420.00↔8,420.00 USD✓
OrderKey · duplicate source id rejected, never doubled
Oracle Fusion orderOrder Hub
OrderKeySHOPIFY:1042
accountPartyNumber 1004182
line 199320 · qty 12
line 244120 · qty 4
statusbooked
Order journey#1042 → Order Hub · 5s end to end
09:42:04webhook received→
09:42:04HMAC ✓ · OrderKey dedup ✓→
09:42:05transformed→
09:42:06salesOrdersForOrderHub→
09:42:09order booked→
09:42:09status → Shopify
drag, scroll, or use the tabs
Inside the platform
Feature by feature.
Ten engineered subsystems, the same ones that run the in-production NetSuite build. What changes per ERP is the adapter, not the machine.
01 / 10
When a record fails
Integrations are judged by how they fail. Follow one failed record.
It is classified before it is retried, and nothing disappears into a log file. Colour carries the verdict: amber is sorted, teal retries, red is held, green replays.
01
It arrives
A write to Shopify or Oracle Fusion fails, or an FBDI callback never lands. Instead of disappearing into a log, it enters the pipeline.
captured→ 02
It gets classified
Every failure is sorted before anything is retried, so a bad record never loops forever.
classified→ 03
Transient retries
Timeouts and HTTP 429 pod throttling retry with exponential backoff and jitter, automatically, until they clear.
→ 04
Permanent is held
A validation or permission failure routes straight to the dead-letter queue for review. It is never retried blindly or lost.
held for review→ 05
You replay it
Fix the cause, replay from the queue. A missed ErpImportBulkDataEvent is recovered by polling ESS job status. A daily reconciliation pass catches the rest.
The failure-mode surface no vendor page admits
Where off-the-shelf Oracle-Shopify connectors break.
Generic connectors map Oracle's standard model, not yours. The edge cases below are exactly where a fixed-mapping connector needs custom logic, in OIC or in bespoke middleware.
Multi-org & ledger routing
highest valueOracle Fusion supports multi-legal-entity, multi-ledger, multi-currency and intercompany natively, but prebuilt connectors do not map an order into the right entity and ledger. Pricing resolves per business unit. That routing logic has to be built.
→ one Shopify store ↔ one Oracle business unitB2B price lists & account hierarchies
highest valueA customer's price resolves through a rank-based waterfall: segment, strategy, price list, discount, agreement. Reading the stored price list gives you the cube, not the resolved price. Generic connectors skip the account hierarchy.
→ call priceSalesTransaction, do not replicate the cubeInventory-org mapping & overselling
commonRaw on-hand over-promises: it includes stock already reserved to other demand. Org, subinventory and locator have to map onto Shopify's flat locations, with non-sellable subinventories excluded and drop-ship handled.
→ feed available-to-reserve, buffer the feedReturns & subledger handoff
commonPartial refunds and cancellations have to reconcile back into Receivables as credit memos with line detail and correct tax allocation. Connectors that collapse multi-line refunds distort item margin and break the audit trail.
→ order return line → receivablesCreditMemosTax & discounts at month-end
commonOracle Fusion Tax is invoice-driven, so it only fires when a transaction exists in Oracle. Cart-time tax belongs in Shopify's engine. If the two sides taxed against different rules, the booked AR invoice would not match the cart.
→ same certified provider on both sidesThe throughput ceiling under peak
highest valueFusion throttles at the pod, runs synchronous calls under 60 to 300 second timeouts, and steers volume above roughly 100 records onto FBDI. A naive per-order REST loop fails under flash-sale load. The OIC Shopify adapter is bound by Shopify's 2 req/sec REST ceiling.
→ buffer / Parking Lot, back off on 429Claims you'll hear vs. what the docs say
Claim, meet reality.
Every reality below traces to a primary Oracle or Shopify source. Your architect can verify each one.
01
The claim"There's a native, turnkey Oracle-to-Shopify connector. Just install it."
The realityThere is no first-party turnkey Fusion-to-Shopify product. What exists is OIC with a Shopify adapter and an ERP Cloud adapter you assemble yourself, plus third-party iPaaS that package some of that assembly. "Use OIC" is a build decision, not a buy decision: you still own the orchestration, FBDI templates, callback wiring, retries, and reconciliation.
02
The claim"The OIC Shopify adapter does everything you need."
The realityThe OIC Shopify adapter is plumbing, not a solution. It supports CRUD invoke and event triggers on common objects, but it ships no business logic. Legal-entity routing, multi-org, contract pricing, buffer logic, and reconciliation are not in the box. OIC gives you the pipes. We build the logic that runs through them.
03
The claim"Oracle and Shopify partnered in 2024, so order-to-cash is handled."
The realityThe Oracle and Shopify partnership announced June 12, 2024 connects Oracle Fusion Cloud Applications and Oracle Unity CDP with Shopify for data and CX flows. It is a data/CX framework, not a turnkey order-to-cash integration. Most order, inventory and finance sync still has to be built.
04
The claim"Just point the connector at our Oracle and it maps everything."
The realityPrebuilt connectors use fixed field mappings against Oracle's standard data model, not your multi-org, price-list, tax and subledger config. The edge cases are exactly where they need custom work. The richest prebuilt Shopify content targets NetSuite, so against Fusion you get a thinner, generic Financials connection.
05
The claim"Sync stock straight from Oracle on-hand."
The realityOracle does not expose a single "available" number, and raw on-hand over-promises: it includes stock reserved to other demand. Feed the storefront available-to-reserve via the
Available Quantity Details resource, never on-hand alone. Drop-ship and back-to-back lines can have zero on-hand yet be fully sellable.06
The claim"Calculate cart tax in Oracle for a single source of truth."
The realityOracle Fusion Tax is invoice-driven: it only fires when a transaction exists in Oracle, so it is not a low-latency storefront tax service. Run cart-time tax in Shopify's engine with the same certified partner (Avalara, Vertex, ONESOURCE) and set Oracle to "calculate tax by tax provider," so the booked AR invoice taxes against the same rules.
07
The claim"Read the price list and you've got the price."
The realityThe price list is only the stored cube. Oracle resolves a customer's price through a rank-based waterfall, and replicating that in middleware is fragile. Call the Price Execution API,
priceSalesTransaction, with the cart context and read back the resolved net price. Oracle does not "shop for the lowest price," lower numeric rank wins.08
The claim"Set up the webhook and trust it. Events just arrive."
The realityBy Shopify's own docs, webhooks are at-least-once and not guaranteed: respond within 5 seconds or delivery fails, Shopify retries up to 8 times over ~4 hours, and after repeated failures in a 24-hour window the subscription is removed. Your connector can stop receiving an event type and not know it. The remedy is reconciliation polling, which most connectors do not ship.
09
The claim"Multi-entity is fine. Oracle handles legal entities, so orders route themselves."
The realityOracle supports multi-legal-entity, multi-ledger and intercompany natively, but prebuilt Shopify connectors don't map orders into the right entity and ledger automatically. Pricing and agreements resolve per business unit. That routing logic has to be built, in OIC or custom middleware. This is the highest-value, most Oracle-specific gap.
10
The claim"It scales. Just fan out an API call per order."
The realityFusion applies pod-level throttling, runs synchronous calls under 60 to 300 second timeouts, and steers volume above ~100 records off per-record REST onto FBDI, with POSTs kept to ≤500 records. A naive per-order loop fails under BFCM load. The proven smoothing pattern is a buffer / Parking Lot that meters a fixed batch with bounded retries and backoff on HTTP 429.
11
The claim"Re-sending an order is safe. It won't duplicate."
The realityOnly if you build for it. Fusion REST is not a generic upsert API. Orders are idempotent because of the
OrderKey, SourceOrderSystem:SourceTransactionId: push the Shopify order id and a repeat is rejected as a duplicate, not doubled. Customers de-dupe only via the Accounts Source System References child. Everywhere else, persist the Oracle internal key and read before write.12
The claim"Custom fields just come through in the API payload."
The realityDFFs and EFFs are child resources hidden behind
expand and are not in the default payload. Request them with expand=DFF, write them via the __FLEX_Context block keyed by the immutable developer API name, not the UI label, and only against published config. Sandbox-configured flexfields are invisible to integrations until published.13
The claim"The bulk import will tell you when it's done."
The realityFusion bulk completion is callback-driven and fragile. A missed
ErpImportBulkDataEvent leaves orders that may or may not have posted, with no automatic notification. Recovery means polling getESSJobStatus and reading ESS execution details. Off-the-shelf connectors rarely build that loop. A custom layer persists, dead-letters and replays.14
The claim"A generic CRUD connector covers the Fusion side."
The realityThe high-throughput Fusion paths are asynchronous, file-based and ESS-job-mediated. There is no synchronous "create this order and tell me it posted" at bulk scale. Generic CRUD-and-polling connectors do not use FBDI or the ERP Integration Service for bulk, so they hit per-record limits without the batch path. The submit, await-callback-or-poll, confirm-or-dead-letter state machine is the real work.
Source of truth, made explicit
What we sync, and which system owns it.
Master data flows one way, Oracle Fusion to Shopify. Orders flow both ways. Oracle stays the system of record on every line.
Oracle → Shopify · one way
Items & pricing
Items via itemsV2, the resolved net price via priceSalesTransaction, B2B and contract pricing per business unit. Browse uses Price Book Retrievals, the live call is reserved for cart.
source of truth · Oracle Fusion
Shopify ⇄ Oracle · both ways
Orders, fulfillments, returns
Orders write to salesOrdersForOrderHub, ship-confirm flows back as the Shopify fulfillment and tracking, returns post as a return line and receivablesCreditMemos. Idempotent on the OrderKey.
written in Shopify · booked in Oracle
Oracle → Shopify · one way
Real-time inventory
Available-to-reserve fed per location with delta updates, only changed quantities. The feed is buffered into Shopify for fast browse, and GOP quickAvailabilityCheck is reserved for true order promising at checkout, not every PDP.
overselling prevented by · buffer logic
The under-served ICP
Built for Shopify Plus, B2B, and Oracle multi-org operations.
The merchants who outgrow a fixed-mapping connector first: enterprise and multi-entity brands whose finance, catalog, or order volume has passed what a generic iPaaS subscription was built to model.
Shopify Plus B2B
Price lists become companies
Oracle price-list and account-hierarchy structure maps onto Shopify B2B companies, locations and catalogs as first-class sync entities, not flattened afterthoughts. The right price level is resolved per company.
customer price list → company catalog
Oracle multi-org
One store, one business unit
The clean topology is one Shopify store to one Oracle business unit. Pricing, agreements and ledger routing all resolve per business unit, so an order lands in the right entity and the right ledger.
store ↔ business unit ↔ ledger
Multi-currency
Resolved server-side
Currency is part of the price context sent to the engine and resolved server-side, so the storefront shows the price the customer will actually be billed, and the booked AR invoice matches it.
currency in · resolved net price out
How long it takes
Scope drives the timeline.
It scales with the number of legal entities, ledgers and sync points. Oracle's longer discovery is acknowledged in the bands below.
Basic · single entity
6–8 weeks
single entity
- Orders, inventory and customers, single business unit
- Resolved pricing via the Price Execution API
- Available-to-reserve inventory with buffer logic
Standard · finance depth
10–12 weeks
finance depth
- Everything in basic
- Multi-currency, tax provider on both sides
- Partial refunds and returns into Receivables
Full · B2B / multi-org
14–20 weeks
B2B / multi-org
- Multi-legal-entity and multi-ledger order routing
- Shopify B2B contract pricing and account hierarchies
- Throughput hardening against the connector ceiling
Cost · scoped per build
A fully custom build is priced as an engineering engagement, a scoped build plus a support agreement, not a per-record meter. Market context for comparison: prebuilt connectors start around $15K and run $30K to $100K for complex multi-entity workflows; platform-only subscriptions start around $99/month; Oracle Integration Cloud itself is priced on message volume. Your band is set from your real order-to-cash flow in the working session.
Security posture
Built to pass your review, and your Oracle team's questions.
Least-privilege access to Oracle Fusion
OAuth 2.0 Client Credentials against OCI IAM, on a dedicated least-privilege service user whose name matches the OAuth Client ID, carrying only the function and data security in scope. Not Administrator.
It runs from declarable egress IPs
Fusion buyers run LBAC, network ACLs and OCI WAF IP allowlisting. The middleware presents stable, declarable egress IPs your team adds to the allowlist, so it never 401s from an un-listed address.
Inbound traffic is verified
Every Shopify webhook is HMAC-verified before it is trusted, then deduplicated by event id so a replay cannot create a second order.
Everything is on the record
Oracle and Shopify secrets are encrypted and rotatable without downtime, and an append-only audit trail logs every operation, source-tagged, so you can prove what happened during close.
The questions we have already answered
Where Oracle Fusion integrations get hard, and where we land.
The details that separate a team that read the docs from a team that shipped against them. Open any one.
01How do you integrate Oracle Fusion Cloud ERP with Shopify?+
Three ways: Oracle Integration Cloud (OIC) with its native Shopify adapter (Oracle's own iPaaS, priced on message volume), a third-party iPaaS or prebuilt connector such as Celigo, Cleo, Alumio, or Commercient SYNC, or a custom-built integration from a Shopify Plus development partner built around your exact order-to-cash flow. The right choice depends on how many legal entities and ledgers you run, your B2B complexity, and integration throughput.
02What is the Oracle Integration Cloud Shopify adapter, and what are its limits?+
It is Oracle's native connector for moving data between Shopify and Oracle Fusion through OIC. Its main hard limit is Shopify's REST Admin API rate cap of 2 requests per second, which throttles high-volume sync unless the integration uses bulk operations, GraphQL, and queuing. It also uses fixed mappings and does not model multi-legal-entity routing, intercompany, or contract pricing out of the box.
03How much does an Oracle Fusion ⇄ Shopify integration cost?+
A prebuilt connector for simple workflows starts around $15,000 including license; complex multi-entity workflows run $30,000–$100,000. Platform-only subscriptions start around $99/month, and Oracle Integration Cloud itself is typically priced on message volume. A fully custom build is scoped per project.
04How long does it take?+
It scales with the number of legal entities, ledgers, and sync points. Single-entity orders, inventory and customers is the fastest scope; multi-currency, tax and partial refunds adds time; full multi-legal-entity / multi-ledger routing with Shopify B2B is the enterprise scope.
05Oracle Integration Cloud vs Celigo vs a custom integration, which is better?+
OIC and Celigo are strong, proven iPaaS options for standard order and inventory sync. A custom build wins when you need multi-legal-entity / multi-ledger routing, multi-currency intercompany, Shopify B2B contract pricing, or throughput that a fixed-mapping connector can't model against the connector's rate ceiling. Makro builds the custom path for Shopify Plus brands that have outgrown an off-the-shelf connector.
06Where do Shopify-Oracle Fusion integrations usually break?+
Four predictable points: legal-entity/ledger routing of orders, multi-currency FX and tax-authority handling, the throughput ceiling under peak load, and partial refund/return reconciliation back into Oracle Receivables. A custom integration is designed to handle all four explicitly with retry logic.
07How do you handle Oracle Fusion pricing at the cart?+
We do not replicate Oracle's rank-based pricing waterfall in middleware, that is fragile. We call the Price Execution API,
priceSalesTransaction, with the cart context (sold-to customer, business unit, currency, lines) and read back the resolved net price. For browse we use Price Book Retrievals and reserve the live call for cart and checkout. B2B and contract pricing all feed the same engine.08How do you keep stock accurate without overselling?+
We feed Shopify available-to-reserve, on-hand minus reservations, via the
Available Quantity Details resource, never raw on-hand which over-promises. The feed is buffered into Shopify's own inventory levels for fast browse, and GOP quickAvailabilityCheck is reserved for true order promising at checkout, not every product page. Org, subinventory and locator map onto Shopify's flat locations.09What about Fusion throttling under real load?+
Fusion governance is pod-level and adaptive, Oracle publishes no fixed requests-per-minute number, so we treat HTTP 429 as the contract and back off with jitter. Volume beyond roughly 100 records moves off per-record REST onto FBDI, with POSTs kept to 500 records or fewer. The proven smoothing pattern is a buffer, a Parking Lot, that meters a fixed batch into the ERP. Storefront traffic never lands raw on Oracle.
10Can Oracle Fusion route Shopify orders across multiple legal entities and ledgers?+
Oracle Fusion natively supports multi-legal-entity, multi-ledger, multi-currency and intercompany processing, but prebuilt Shopify connectors don't map orders into the right entity and ledger automatically. That routing logic has to be built, either in OIC or in a custom middleware layer.
11Do our custom fields come through, and are we locked in?+
Your DFFs and EFFs come through, but they are child resources behind
expand, not in the default payload, and they are written via the __FLEX_Context block keyed by the immutable developer API name, only against published config. We introspect the flexfield metadata instead of hard-coding. On the Oracle side we use standard published surfaces only, REST, FBDI, BICC, business events, OCI IAM. The middleware is our platform, but your data, your mappings and the full audit trail are yours, documented and exportable.12Will rollout touch our production ledger?+
Not until you decide it does. Master data syncs are read-only against Oracle Fusion. Order writes go to a test environment first, then through a parallel-run with daily reconciliation. Production booking starts when the reconciliation report says zero drift and you sign off, and the append-only audit trail covers every record from day one.
The framework underneath
A proven platform. Oracle Fusion is the next first-class adapter.
Every ERP sits behind the same contract: authenticate, fetch master data, push orders, validate, report. The platform runs in production today against NetSuite. Oracle Fusion Cloud ERP is a registered target on that same framework, its path mapped to REST, FBDI, BICC, business events and OAuth 2.0 via OCI IAM.
We say this plainly: the credibility is a real platform and a precisely understood Oracle Fusion path, not a decade of Oracle traffic. That distinction is exactly what your architect can verify, which is why we lead with it.
adapter contractbase.ts
01authenticate()OCI IAM / OAuth
02fetchMasterData()REST / FBDI / BICC
03pushOrder()Order Hub
04validate()schema check
05report()audit + status
NS
NetSuite
ERP adapter
OF
Oracle Fusion Cloud ERP
ERP adapter
The engineering standard
Claims you can check.
Oracle Fusion is path mapped, not yet in production, so the proof is the platform itself, and a NetSuite ERP integration the same platform already runs. The numbers are counted in the repository, not rounded for the slide.
$100K+ / yr
Clarius · NetSuite + Salesforce + Shopify PlusThe same platform already runs an ERP integration in production. For Clarius, Makro unified NetSuite ERP, Salesforce CRM and Shopify Plus into a single account view of orders and invoices, with Shopify Flow feeding order data into NetSuite, eliminating manual order entry and reducing operational costs by over $100,000 annually. That is a NetSuite outcome, documented on the NetSuite page, and it evidences the platform's ERP-integration track record. There is no Oracle Fusion outcome to claim yet, and we will not borrow one.
1,756
Automated tests across 139 suites, run on every change. No code reaches your production data without passing them.
85%
Coverage gate enforced before any deploy.
39
End-to-end browser tests, Chromium, Firefox, WebKit.
7
Failure classes, each with its own pre-decided policy.
0
Credentials stored in plaintext, anywhere, ever.
Bring your Oracle Fusion architect and your OIC or renewal quote. We will walk the platform, not a deck.
A real conversation about your Oracle Fusion environment, your data, and the three sharp questions you already have.