REST APIs Aren’t Just for Tech People

When most people hear “REST API,” they picture developers, code editors, and Postman screens full of brackets and braces. But here’s the thing, if you work in a functional role on Oracle Fusion, whether that’s Supply Chain, Manufacturing, Quality, or Procurement, you are already closer to APIs than you think. Every page you click through in Fusion is, behind the scenes, talking to a REST API. And with the Redwood UI, this connection is more visible and more usable than it has ever been. 

This post is written for functional consultants, business analysts, and power users, not just developers. The goal is simple: show you what a REST API actually is in plain terms, how to find the exact API behind any Fusion page using nothing but your browser, and how to use that API with Excel to view, describe, and even mass, upload data without writing a single line of code. 

What is a REST API, in Plain Language?

Think of a REST API as a structured way for two systems to ask each other for information or send each other updates, using a web address (a URL) instead of a screen. When you open the Inspection Results page in Fusion, the page itself doesn’t “contain” the data, it sends a request to a REST API behind the scenes, gets back the data in a format called JSON, and displays it nicely on screen. 

The same API that the page uses internally is also available to you directly. That means anything you can see on a Fusion page; you can usually also retrieve, filter, or update through that same API, including a tool as familiar as Excel. 

Finding the API Behind Any Fusion Page (No Developer Tools Needed)

Every modern browser has a built, in feature called “Inspect” or “Developer Tools.” You do not need to know how to code to use it for this purpose; you are simply watching the conversation your browser is already having with Fusion. 

Step-by-Step: How to Find the API Call for Any Page 

1. Open the Fusion page you want to investigate (for example, the Inspection Results page, or the Purchase Orders work area).
2. Rightclick anywhere on the page and select “Inspect” (or press F12 on Windows, or Cmd+Option+I on Mac). 
3. A panel opens on the side or bottom of the browser. Click on the tab labelled “Network.”
4. With the Network tab open, refresh the page (F5) or perform the actionyou’reinvestigating (e.g. searching for a Work Order). 
5. You’ll see a list of requestsappear. Look for entriescontaining “fscmRestApi”; these are the Fusion REST API calls. 
6. Click on one of these “fscmRestApi” entries. On theright,handside, you’ll see tabs like “Headers,” “Payload,” “Preview,” and “Response.” 
7. The “Headers” tab shows you the full URL beingcalled;this is the actual API endpoint and resource name. 
8. The “Response” or “Preview” tab shows you the JSON datareturned;this is exactly what the page is displaying, just in raw form. 
9. If the URLcontainsan identifier (a long number), that is usually the record’s unique Event ID, Order ID, or similar key, this is how the page knows which specific record to display. 

That’s it. No login to a developer portal, no special tools, just the browser you already use every day. Once you can see the URL, you effectively have the “address” of that data, and you can reuse it elsewhere. 

Why This Matters for Functional Users

Once you know how to find and read these API calls, a few doors open: 

• You can describe data requirements precisely to developers, instead of saying “I need the inspection data,” you can say “I need the samplesAndResults child resource for the inspectionEvents API.” 
• You can pull data into Excel directly using Oracle’s Visual Builder Add,in for Excel, without waiting for a custom report. 
• You can validate what a custom page or integration should be doing, by comparing it against the standard API response. 
• You can prepare and validate mass data uploads in Excel, then push them through the same API used by the page, turning a manual, page,by,page task into a single batch update. 

Using REST APIs with Excel, Viewing, Describing, and Mass Uploading Data 

Oracle provides a Visual Builder Add,in for Excel that connects directly to Fusion REST APIs. Once connected, each REST resource (like Purchase Requisitions, Purchase Orders, or Inspection Events) appears as a table inside Excel, similar to a regular spreadsheet, but linked live to Fusion. 

With this connection, a functional user can do three things without any coding: 

• View, pull existing records into Excel exactly as they exist in Fusion, including all fields available on that API. 
• Describe, use Excel’s own structure (column headers, filters, comments) to document what each field means, which fields are mandatory, and what values are expected, turning the spreadsheet into a living field mapping document. 
• Mass Upload, fill in new rows or update existing rows in Excel, then submit the changes back to Fusion through the same API, updating many records in one go instead of one screen at a time. 

Worked Examples, Mixing Different Modules 

The beauty of REST APIs is that the same approach works across modules, Manufacturing, Quality, and Procurement all follow the same pattern: a header resource, child resources for line level detail, and an action or PATCH for updates. Below are a few real examples. 

Example 1, Quality: Inspection Events (Manufacturing / Quality Management) 

This is the API behind the Inspection Results custom page discussed earlier in this series. 

Get the inspection header for a specific Work Order: 

GET /fscmRestApi/resources/11.13.18.05/inspectionEvents?q=WorkOrderNumber=WP1232 

Once you have the IpEventId from the response above, get the characteristic,level results: 

GET /fscmRestApi/resources/11.13.18.05/inspectionEvents/{IpEventId}/child/samplesAndResults 

A functional user can pull both of these into Excel, see every field the inspection page uses (CharacteristicName, TargetValue, SampleStatus, etc.), and use that as a ready,made field mapping reference for an FDD, exactly the kind of table used earlier in this series. 

Example 2, Procurement: Purchase Requisitions 

The Purchase Requisitions REST resource works the same way, a header with requisition level details, and child resources for lines. 

Get all requisitions for a requisitioning business unit: 

GET /fscmRestApi/resources/11.13.18.05/purchaseRequisitions?q=RequisitioningBU=’Vision Operations’ 

Get the lines for a specific requisition: 

GET /fscmRestApi/resources/11.13.18.05/purchaseRequisitions/{requisitionId}/child/lines 

Pulled into Excel, a procurement analyst can review hundreds of requisition lines at once, filter by category or status, and identify exactly which fields drive approval routing, all without opening each requisition individually in Fusion. 

Example 3, Procurement: Purchase Orders 

Similarly, Purchase Orders expose header and line,level data through REST: 

GET /fscmRestApi/resources/11.13.18.05/purchaseOrders?q=POHeaderId=300100551759371 

Get the order lines: 

GET /fscmRestApi/resources/11.13.18.05/purchaseOrders/{POHeaderId}/child/lines 

This is useful for mass,validating PO data before month,end close, or for preparing a bulk update (for example, updating delivery dates across many PO lines) by editing values in Excel and pushing them back through the same resource. 

Redwood Makes This Even More Accessible

With the move to Redwood pages, almost every page in Fusion is now built on top of REST APIs in a consistent, predictable way. This is a significant shift for functional users; the older Classic pages were often built on different underlying technologies, making it harder to map a screen field to an API field. 

With Redwood, what you see on screen and what the API returns are far more aligned. This means the technique described in Section 2, opening the browser Network tab and inspecting the call, works more reliably and consistently across the application than it ever did before. 

Key Takeaways

• A REST API is simply a structured address for data, the same data you already see on a Fusion page. 
• You can find the exact API behind any page using your browser’s built,in Inspect / Network tools, no developer access required. 
• Knowing the API name and fields helps you communicate precisely with developers and write better functional specs. 
• Excel, via the Visual Builder Add in, lets functional users view, document, and mass update Fusion data using the same APIs the pages use. 
• The pattern is consistent across modules, Quality, Manufacturing, and Procurement all follow header + child resource + PATCH/action structures. 
• Redwood pages make this technique more consistent and more useful than ever, because the UI and the API are now closely aligned.