Oracle Fusion REST API vs SOAP Web Services: Which One Should You Use?

Nine separate Cloud Customer Connect threads, across nine different Oracle Fusion modules, all ask a version of the same question: REST or SOAP? Lease accounting. Receivables debit-memo extraction. Customer creation and update. Contract project invoice status. A DFF update on an AR miscellaneous receipt. Sales order external-approval submission. A PPM financial plan. Mass-applying AR unapplied receipts. Procurement category hierarchy management. None of them get a single, module-agnostic answer — because there isn’t one. Here’s Oracle’s actual direction, where SOAP still legitimately wins, and — more useful than either — a method for checking which one applies to your specific business object in under a minute, instead of guessing or waiting on a forum reply.

Oracle’s actual direction: REST-first, not REST-only

Where Oracle has taken a public position, it’s unambiguous. A-Team Chronicles’ integration guide states plainly that “usage of REST APIs for connecting to [Fusion applications] is strongly recommended over using SOAP APIs” for the customer- and party-management flows it covers. (Integrating with Fusion Applications Using SOAP Web Services and REST APIs, A-Team Chronicles) Oracle Field Service goes further and ships an official field-by-field mapping table from its legacy SOAP operations to their REST replacements — direct evidence that specific SOAP services are being retired module by module as REST equivalents ship, not all at once. (SOAP APIs to REST APIs Mapping, Field Service)

But “REST-first” is a direction, not a fact about every corner of today’s catalog. Oracle’s own Supply Chain & Manufacturing documentation has a page titled, with refreshing honesty, “REST APIs and SOAP Services (Inbound)” — for parts of Product Lifecycle Management, SOAP is still the documented, supported way in. (REST APIs and Soap Services (Inbound), docs.oracle.com) Some business objects have a REST resource today. Some don’t yet. Nothing about the module tells you which — you have to check the specific object.

What the nine threads have in common

Skimming Cloud Customer Connect turns up real, unresolved versions of this question across nearly every pillar: lease accounting, receivables debit memos, customer creation and update, project contract invoice status, a DFF on an AR misc receipt, sales order external approval, a PPM financial plan, mass-applying AR unapplied receipts, and procurement category hierarchy management. Nine threads, nine different modules, the same open question, and no consultant or vendor guide anywhere answers the general case — because the general case doesn’t have one answer.

What they share isn’t the business object — it’s the method. Every asker went straight to a forum instead of the one place that actually has the answer for their specific object: the REST catalog itself.

The one-minute check, before you ask or assume

Before assuming SOAP is required for a given object, search for it directly:

1. Search the REST catalog by business term — “lease,” “receivable,” “category hierarchy,” whatever the object is called in the Fusion UI. A tool like OPAL indexes the full published catalog offline and searches it in milliseconds; Oracle’s own /describe action on a candidate resource does the same thing live against your instance.
2. If a matching resource exists, check what it actually supports. Some REST resources are read-only (GET only) even when the object is fully writable through the UI or SOAP — the presence of a resource doesn’t guarantee POST/PATCH support for your specific scenario. Check the operations list, not just whether the resource name exists.
3. If nothing matches, check the module’s own SOAP web services list (each pillar publishes one — Financials, SCM, Procurement, HCM all have their own) to confirm SOAP is the documented path, rather than assuming it by default.
4. If it’s a bulk scenario — mass-apply, mass-update, a full-table load — neither REST nor SOAP is usually the right tool regardless of which one technically supports it. See our bulk/batch operations and rate limits posts for why FBDI (import) and BICC (extract) exist specifically for this case, and where the practical ceiling on REST-based bulk operations sits.

This reverses the order every one of the nine threads followed. Ask the catalog first; ask a forum only if the catalog is genuinely silent.

When SOAP is still the right call

• The object has no REST resource today, confirmed by the check above — not assumed because the module “feels old.”
• Oracle’s own documentation still lists SOAP as the supported inbound path, the way PLM’s inbound-services page does.
• A stable, already-built SOAP integration has no REST-equivalent driver to migrate to yet — Oracle is retiring SOAP service-by-service as REST ships, per the Field Service mapping table, not deprecating it wholesale on a fixed date.

Where this fits with everything else

For the mechanics once you know you’re on REST — filtering, pagination, authentication, and the rest — see the Oracle Fusion API guide and the full endpoint catalog. For the specific “don’t use REST for this” case, bulk/batch operations and rate limits cover FBDI/BICC in more depth.

---

This post is part of our complete Oracle Fusion API guide — auth, base URLs, q filters, and the full endpoint catalog in one place.