Oracle

Oracle sells three different ERP products and they share almost nothing except the vendor's name. Oracle Fusion Cloud Applications, the SaaS suite covering ERP, SCM, Procurement and HCM, exposes a large REST surface under /fscmRestApi and is what a new Oracle customer buys today. Oracle E-Business Suite, the on-premises product still running in a great many manufacturing and distribution businesses, exposes nothing until someone installs and configures the Integrated SOA Gateway, at which point individual PL/SQL APIs can be deployed one by one as REST services. Oracle NetSuite is a separate code line entirely and is covered at /connectors/netsuite. This page covers Fusion and E-Business Suite and labels every endpoint with which one it belongs to. Establish the product and, for E-Business Suite, whether the gateway is even installed, before anything else.

At a glance

What it is

Oracle Fusion Cloud Applications is Oracle's SaaS enterprise suite, running on Oracle's own infrastructure with quarterly updates the customer cannot fully defer. For a commerce business the relevant pillars are Order Management (the order capture and orchestration engine, branded Order Hub when it is receiving orders from external systems), Inventory Management, Product Management (the item master), Shipping, and Receivables. Each pillar contributes REST resources to the same /fscmRestApi service, so one base URL and one credential reach all of them.

Oracle E-Business Suite is the previous generation, first shipped in the 1990s, still under Premier Support through 2034 on release 12.2. It is installed on the customer's own servers or on their own cloud tenancy. There is no API by default. The Integrated SOA Gateway ships with it but has to be configured, and then each interface in the Integration Repository (a PL/SQL API, a Java bean service, an application module service) is individually deployed as a REST service with an alias. What is reachable is therefore entirely a function of what that customer's DBA deployed, which is why two E-Business Suite integrations rarely look alike.

Neither product is a sales channel. Neither has listings, marketplace product identifiers or channel-specific prices. Fusion's Order Hub exists precisely to receive orders captured elsewhere, which is the right shape for a commerce connector: push orders in, pull stock and invoices out.

API access

Fusion Cloud

There is no developer console and no self-serve signup. The customer's Fusion administrator creates a user, assigns job roles that carry the relevant REST privileges, and gives you the pod host name. Host names look like https://<pod>.fa.<region>.oraclecloud.com.

Service paths are grouped by pillar:

The version segment 11.13.18.05 has been stable across every quarterly update since it was introduced and is not a moving version number in the usual sense. Oracle also accepts latest in that slot, and Oracle's own sample code uses both: oracle/fusion-ai-studio calls /fscmRestApi/resources/11.13.18.05/onhandQuantityDetails in one business object and /fscmRestApi/resources/latest/inventoryAccessibleOrganizations in another. Prefer the pinned version in production; latest will move under you.

Discovery is built in. GET /fscmRestApi/resources/11.13.18.05/ lists the resources the pod exposes, and appending /describe to a resource returns its full attribute list, child resources, actions and finders. Because customers add extensible flexfields, the describe output for a given pod is authoritative in a way that Oracle's published reference is not. Run describe first.

E-Business Suite

1. The DBA installs and enables the Integrated SOA Gateway, which is not on by default.
2. In the Integration Repository, they find the interface you need, select the methods, and deploy it as a REST service with a service alias.
3. The service is then reachable at https://<ebs host>/webservices/rest/<serviceAlias>/<methodName>/, described by a WADL document at the alias root.
4. They grant the applications user the responsibility that owns that interface.

Nothing outside that deployed set exists. If a required API has not been deployed, the answer is a change request, not a workaround.

SDKs

Oracle publishes no general client library. What exists and is worth using: oracle-samples/node-red-nodes includes a fusion-scm-nodes package with request validation logic that documents the supported media types and batch semantics; oracle/fusion-ai-studio publishes business object definitions containing real, working resource paths and query strings; and the Oracle Integration Cloud ERP adapter is the supported route if the customer already owns Oracle Integration. For everything else, write plain HTTP.

Authentication

Fusion, basic auth

This is what almost every integration actually uses, and it is what Oracle's own adapters and every third-party connector default to.

1. The customer creates a dedicated integration user in the Fusion identity domain.
2. They assign job roles. REST access is privilege-driven, so a 403 on one resource and a 200 on another with the same credential is normal and means a missing privilege, not a broken token.
3. Every request carries Authorization: Basic base64(username:password).
4. Nothing expires, but the identity domain's password policy applies, so the password will rotate on the customer's schedule. Build rotation in.

curl -u 'INTEGRATION_USER:secret' \
  -H 'Accept: application/json' \
  'https://mypod.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/onhandQuantityDetails?q=ItemNumber=%27FG-OIL-GN-1000%27&onlyData=true&limit=25'

Fusion, OAuth 2.0 and JWT bearer

Oracle Cloud Infrastructure IAM (and, on older pods, Oracle Identity Cloud Service) can issue tokens for Fusion. A confidential application is registered in the identity domain, given the Fusion application as a resource, and then either the client credentials grant or a JWT assertion is used. The token goes in Authorization: Bearer <token>. SAML 2.0 bearer is also supported for federated scenarios.

Oracle documents this under its Multi Token Over SSL policy, which is why all four mechanisms (basic, SAML bearer, JWT bearer, OAuth 2.0) work against the same endpoints. The exact token endpoint is per identity domain and is not reproduced here because it is tenant-specific.

E-Business Suite

Two options on the same gateway:

1. Basic auth, Authorization: Basic base64(user:password) on every service call.
2. Token, GET /webservices/rest/login with basic auth, which returns an access token both as a Set-Cookie cookie named accessToken and in the response body. Send that cookie on subsequent calls and end with GET /webservices/rest/logout.

Every service call also needs a REST header block inside the request body identifying the applications context:

POST /webservices/rest/purchaseOrders/createPurchaseOrder/ HTTP/1.1
Host: ebs.example.com
Authorization: Basic <base64>
Content-Type: application/json

{
  "RESTHeader": {
    "Responsibility": "PURCHASING_SUPER_USER",
    "RespApplication": "PO",
    "SecurityGroup": "STANDARD",
    "NLSLanguage": "AMERICAN",
    "Org_Id": "204"
  },
  "InputParameters": {
  }
}

The RESTHeader is not optional. Responsibility, RespApplication, SecurityGroup and Org_Id together decide which operating unit the call runs against, and getting Org_Id wrong silently writes to the wrong legal entity.

Multi-account

One Fusion pod is one customer, sometimes with several business units and inventory organizations inside it. The credential store keys on (pod host, product, user) and must also record the business unit id and the inventory organization ids, because order and stock resources are scoped by them. E-Business Suite adds a second dimension: the same credential behaves differently depending on which responsibility you declare, so the store must hold responsibility and Org_Id alongside the password.

Objects we can read

Fusion paths below are relative to https://<pod>.fa.<region>.oraclecloud.com/fscmRestApi/resources/11.13.18.05.

Common query parameters, all verified from Oracle's own business object definitions:

A collection response is always the same envelope:

{
  "items": [],
  "count": 25,
  "hasMore": true,
  "limit": 25,
  "offset": 0,
  "links": []
}

hasMore drives the paging loop. count is the size of this page, not the total.

Orders

GET /salesOrdersForOrderHub and GET /salesOrdersForOrderHub/{orderKey}, with child collections under /child/lines.

Order Hub is Oracle's inbound order capture surface, so its field names are source-system oriented: an order is identified by the quartet SourceTransactionSystem, SourceTransactionId, SourceTransactionNumber and SourceTransactionRevisionNumber, in addition to Oracle's own HeaderId and OrderNumber. That quartet is the idempotency mechanism: resubmitting the same source transaction identifiers updates rather than duplicates.

Required header fields on create, taken from a working integration: BusinessUnitId, SourceTransactionId, SourceTransactionNumber, SourceTransactionRevisionNumber, SourceTransactionSystem, TransactionOn, and HeaderId on update. Other header attributes in common use are BuyingPartyId, BuyingPartyName, BuyingPartyNumber, BuyingPartyContactId, TransactionType, RequestedShipDate, RequestedArrivalDate, TransactionalCurrencyCode, FreezePriceFlag, FreezeShippingChargeFlag, PartialShipAllowedFlag, CanceledFlag, SubmittedFlag, SalesChannelCode, and a billToCustomer child array.

Sample response not published in a form we could verify. Run GET /salesOrdersForOrderHub/describe against the customer's pod for the authoritative attribute list, including their flexfields.

Order items

GET /salesOrdersForOrderHub/{orderKey}/child/lines, or GET /salesOrdersForOrderHub?expand=lines&onlyData=true to pull them inline.

Lines carry the source transaction line identifiers mirroring the header quartet, ProductNumber or InventoryItemId, OrderedQuantity, OrderedUOM, UnitListPrice, UnitSellingPrice, ExtendedAmount, RequestedShipDate, RequestedArrivalDate, FOBPointCode, Warehouse (the inventory organization code, for example 1BL) and a FulfillLineId. Fulfilment progress is on the fulfilment lines, which are a separate child collection, not on the order line itself.

Attribute names above are from a working third-party integration rather than Oracle's reference; confirm against describe.

Products and listings

GET /itemsV2 in Product Management. Items are keyed by ItemNumber within an OrganizationCode, which matters: the same item exists separately in every inventory organization it is assigned to, with its own attributes. itemsV2 has child resources for categories, relationships, revisions, attachments and translations.

Fusion has no listing concept and no channel product identifier. The unified listings table can only be filled for sku, price and stock.

Inventory

Three resources, all verified against Oracle's own repository.

On-hand quantity by item: GET /onhandQuantityDetails. Oracle's own business object queries it as /fscmRestApi/resources/11.13.18.05/onhandQuantityDetails?q=InventoryItemId='{ItemId}' and describes it as read-only detail of current inventory quantities for an item within an organization, in primary and secondary units of measure. Attributes include OnhandQuantity, PrimaryUOMCode and the secondary unit fields.

Shortage and stockout by location: GET /itemShortageDetailsByLocations, which takes a finder rather than a plain filter:

GET /fscmRestApi/resources/11.13.18.05/itemShortageDetailsByLocations
  ?finder=findStockoutORShortageItems;bindContext=STOCKOUT,bindActualDemandDays=1,bindCatalogId="<id>",bindCategoryId="<id>",bindOrganizationId="<id>"
  &q=ItemNumber='FG-OIL-GN-1000'
  &onlyData=true

This is the shape of most useful Fusion inventory queries: a named finder with bind variables, plus a q on top. Finders are per-resource and are listed in the describe output.

Organizations: GET /inventoryAccessibleOrganizations?fields=OrganizationName,OrganizationId,OrganizationCode&onlyData=true returns the inventory organizations the calling user can reach. Fetch this first and cache it; OrganizationId is the bind value every other inventory query needs.

There is also an onhandBalances style resource in some pods with a different shape. Which on-hand resources a given pod exposes depends on its release and its enabled features, so enumerate /fscmRestApi/resources/11.13.18.05/ rather than assuming.

Sample response not published in a form we could verify for any of these.

Shipments and tracking

Shipping is a distinct Fusion pillar with its own resources covering shipments, shipment lines and packing units. The exact resource names were not verifiable from the sources available on 2026-09-21, so they are deliberately not named here. Enumerate the service catalogue and run describe.

What is safe to say: Fusion records a shipment against fulfilment lines, holds a ship date and a waybill or tracking number where the customer's shipping method captures one, and does not store carrier scan events. Delivery status has to come from the carrier.

Returns and cancellations

Cancellation of a sales order is a field, not a delete: PATCH /salesOrdersForOrderHub/{orderKey} with CanceledFlag set to true, or the same at line level. Return orders in Fusion are ordinary sales orders with a return transaction type and negative or return-flagged lines, created through the same salesOrdersForOrderHub resource. The financial credit is a credit memo in Receivables.

Payments and settlements

GET /receivablesInvoices is the Receivables invoice resource, and it supports create, read, find, update and delete. Credit memos are invoices with a credit transaction type. Payables has a parallel invoices resource for the purchase side, plus payments with stop and void actions.

Fusion has no marketplace settlement object. Channel payouts have to be reconciled against Receivables invoices on whatever reference the connector wrote into the invoice, usually the source transaction number carried from Order Hub.

Attribute names for receivablesInvoices were not verifiable here; run describe.

Customers

Customer data lives in Trading Community Architecture and is reachable from both /fscmRestApi and /crmRestApi depending on which view you want. On the order itself, the customer appears as BuyingPartyId, BuyingPartyName and BuyingPartyNumber, with contacts as BuyingPartyContactId. All names, addresses, emails and phone numbers are PII and Fusion does not mask them.

Locations

GET /inventoryAccessibleOrganizations is the practical locations table: OrganizationId, OrganizationCode, OrganizationName. Below an organization sit subinventories and locators, which is where itemShortageDetailsByLocations reports. A connector that flattens Fusion locations to one level will lose the subinventory split that the warehouse actually operates on.

Writing back: listings, price and stock

Sales orders in

POST /salesOrdersForOrderHub with the header attributes and a nested lines array, then PATCH the returned HeaderId with SubmittedFlag: true to release it into fulfilment.

POST /fscmRestApi/resources/11.13.18.05/salesOrdersForOrderHub?onlyData=true HTTP/1.1
Host: mypod.fa.us2.oraclecloud.com
Authorization: Basic <base64>
Content-Type: application/vnd.oracle.adf.resourceitem+json

{
  "SourceTransactionSystem": "OPS",
  "SourceTransactionId": "D2C-98217",
  "SourceTransactionNumber": "D2C-98217",
  "SourceTransactionRevisionNumber": 1,
  "BusinessUnitId": 300000001234567,
  "TransactionOn": "2026-09-19T10:14:00+00:00",
  "BuyingPartyNumber": "C00420",
  "TransactionalCurrencyCode": "INR",
  "RequestedArrivalDate": "2026-09-22T00:00:00+00:00",
  "lines": [
    {
      "SourceTransactionLineId": "1",
      "SourceTransactionLineNumber": "1",
      "SourceScheduleNumber": "1",
      "ProductNumber": "FG-OIL-GN-1000",
      "OrderedQuantity": 24,
      "OrderedUOMCode": "Ea",
      "Warehouse": "1BL"
    }
  ]
}

Content type matters. Oracle's own validation code in oracle-samples/node-red-nodes enumerates four request media types: application/vnd.oracle.adf.resourceitem+json for a single item, application/vnd.oracle.adf.action+json for an ADF action (which must be POST), application/json, and application/vnd.oracle.adf.batch+json for batch. Sending plain application/json to a resource that expects the ADF item type gives an unhelpful 400.

Invoices in

POST /receivablesInvoices creates a Receivables invoice directly. In most Fusion deployments the invoice is generated by AutoInvoice from the fulfilled order rather than pushed in, and pushing an invoice for an order Fusion already knows about will double-count revenue. Establish which direction the customer wants before building this.

Stock adjustments in

Fusion does not let you set an absolute on-hand quantity through a simple PATCH. Stock changes are inventory transactions: a miscellaneous receipt, a miscellaneous issue, a subinventory transfer, or a cycle count adjustment, each posted as a transaction against an organization, subinventory and locator. The REST resource that accepts them varies by release and by whether the customer runs the transaction interface or the newer staged-transaction resources, and it was not verifiable from the sources available here. Enumerate the catalogue and run describe before designing this path.

The reliable alternative at volume is FBDI, described next.

Bulk: erpintegrations and FBDI

For anything above a few hundred records, Oracle's supported mechanism is File-Based Data Import driven through the erpintegrations resource.

1. POST /fscmRestApi/resources/11.13.18.05/erpintegrations with an importBulkData operation, carrying the data file as a Base64 zip together with the interface details, the job package and job definition names, and the parameters. This uploads to Oracle's content server and submits the Enterprise Scheduler job in one call.
2. Alternatively split it: uploadFileToUCM stages the file, then submitESSJobRequest runs the job against it.
3. Poll for completion with the ESSJobStatusRF finder on erpintegrations, or through the scheduler at /ess/rest/scheduler/v1/requests.
4. Retrieve the output and error files from the content server by document id.

The same erpintegrations resource handles export in the other direction. This is a file pipeline dressed as REST, with all the latency that implies: minutes, not milliseconds. Use it for nightly item and price loads, never for an order that a customer is waiting on.

These erpintegrations operation names come from third-party integration documentation rather than Oracle's reference, which we could not read; treat them as medium confidence and confirm against the pod.

Price

Item prices in Fusion live in pricing strategies, price lists and pricing rules, not on the item. itemsV2 carries cost and list attributes but changing them does not change what an order is priced at. The Pricing pillar has its own REST resources. If the connector's job is to push a channel price into Oracle, the target is a price list line, and the customer's pricing administrator has to tell you which price list.

Batch

POST to the API-version root with Content-Type: application/vnd.oracle.adf.batch+json and a body listing parts. Oracle's own validation code states the constraints plainly: the batch request must target the exact configured API-version root with no query string, must be POST, and supports the operations get, create, update, replace, delete and invoke, of which create, update and replace carry bodies.

E-Business Suite writes

Everything is POST /webservices/rest/<serviceAlias>/<methodName>/ with a RESTHeader and an InputParameters object whose shape is the PL/SQL API's parameter list. Order entry is normally OE_ORDER_PUB.PROCESS_ORDER, inventory movement is normally the transaction interface, and both must have been deployed from the Integration Repository first. There is no generic write.

Webhooks and notifications

Neither product has webhooks you can subscribe to over the API.

Fusion raises internal business events, including order state changes in Order Management. Those events are consumable by Oracle Integration Cloud, which can then call your endpoint. That makes the practical answer: if the customer owns Oracle Integration, ask them to build the subscription and have it POST to you; if they do not, poll.

E-Business Suite has the Business Event System and workflow, which a developer can wire to an outbound call, but again that is custom work in the customer's instance.

Polling

Fusion resources generally expose a last update timestamp attribute, commonly LastUpdateDate, filterable through q:

GET /salesOrdersForOrderHub?q=LastUpdateDate > '2026-09-21T00:00:00+00:00'&orderBy=LastUpdateDate&limit=200&onlyData=true

Confirm the attribute name per resource with describe, because it is not universal and some resources expose it only on child collections.

Suggested intervals: orders and fulfilment lines every 10 minutes, on-hand quantities every 15 minutes scoped to the organizations that matter, Receivables invoices every 30 minutes, items and organizations nightly. Always pair fields= with onlyData=true; a Fusion resource with its HATEOAS links and full attribute set can be ten times the size of what you need.

Rate limits and pagination

Oracle does not publish a numeric REST rate limit for Fusion Cloud that we could verify from a first-party source. A widely circulated third-party figure is roughly 5,000 calls per hour per user; treat that as unverified. What is certain is that Fusion REST runs on the same middle tier as the user interface, so a heavy integration degrades the customer's own screens, and the customer's administrator will notice. Agree a concurrency ceiling with them and stay under it. Four to eight concurrent requests is a reasonable opening position.

Practical notes that matter more than the limit:

• onlyData=true should be on every read. The links arrays are large and useless to a connector.
• totalResults=true should be off. Page until hasMore is false instead.
• Filters with UPPER(...) like UPPER('%text%') are supported, as Oracle's own business objects show, but they are table scans. Filter on indexed identifiers where you can.
• Finders are usually much faster than an equivalent q, because they map to a tuned server-side query. Read the describe output for the finders a resource offers before writing a filter by hand.
• FBDI through erpintegrations is the right answer for volume and it is asynchronous. Budget minutes.

Mapping to the unified model

orders

order_items

products and listings

inventory

shipments, returns, settlements, customers, locations

Gaps and open questions

• docs.oracle.com would not serve a REST reference page to our fetcher. Every attribute list and every resource name on this page should be checked against the customer's own /describe output, which is authoritative for their pod anyway.
• Fusion Shipping resource names, and therefore the whole shipments mapping, are unverified.
• The REST resource that accepts an inventory transaction (miscellaneous receipt, issue, subinventory transfer) is unverified. FBDI is the fallback that certainly works.
• receivablesInvoices attribute names are unverified.
• The erpintegrations operation names (importBulkData, uploadFileToUCM, submitESSJobRequest, the ESSJobStatusRF finder) come from third-party documentation. They are consistent across several independent sources but were not read from Oracle.
• No first-party rate limit figure was found. The circulating 5,000 calls per hour per user number is unverified and should not be designed against.
• Whether the customer has Oracle Integration Cloud decides whether near-real-time notification is possible at all. Ask in the first conversation.
• For E-Business Suite, nothing can be scoped until the customer lists which Integration Repository interfaces they have deployed. That list is the entire specification of what the connector can do.
• Fusion quarterly updates can add attributes and, occasionally, change finder behaviour. A describe diff per release should be part of the connector's maintenance.

Sources

• Oracle Fusion Cloud Supply Chain and Manufacturing documentation and Fusion Cloud Financials documentation, both of which redirected to landing pages for our fetcher on 2026-09-21
• Oracle business object definitions carrying real Fusion REST resource paths, finders and query strings, release 26C, at oracle/fusion-ai-studio
• Oracle Fusion SCM request media types, batch operation set and base path rules, at oracle-samples/node-red-nodes, fusion-scm-nodes
• Order Hub sales order create and submit semantics, required header fields and the SubmittedFlag pattern, from a working integration at wolseleyuk/fscm
• Oracle Fusion Cloud ERP basic auth configuration and the /fscmRestApi/resources/11.13.18.05 base path, at activepieces/activepieces
• Oracle E-Business Suite Integrated SOA Gateway REST surface, login token flow, RESTHeader and InputParameters shape, from the reconstructed OpenAPI at api-evangelist/oracle-e-business-suite
• Fusion authentication options, pagination parameters and erpintegrations bulk operations, from a third-party knowledge base at thawanrungt-ux/OIC-Claude, medium confidence
• FBDI through erpintegrations and ESS job submission, from sharpenskill/fusionfintech and Data-Studio-App/pyoracloud