BOSS REST API in Fusion Applications
Developers knew the business object they needed but not its API. I brought each object’s endpoints, request structure and sample code into Fusion, one click from the record.
Role
Team
Timeline
Outcome
Names, data and screens are modified for confidentiality. The process and my contribution are accurate.
API context sits beside the record, not in a separate site. Try “View API”: the endpoints for Leads open in place, and the records are one click back.
Developers knew the business object, not the endpoint
Developers, integrators and implementation consultants start from something they can see in Fusion, such as a lead, a tag or a service request.
BOSS endpoints expose those business objects so apps can read and change their data. But the API behind each object lived on a separate documentation site organised by endpoint path. To use it, people left the app, searched for the right resource, read its properties and operations, then pieced a request together by hand.
A developer who starts from “Leads” has to work out which style, which version and which path apply before writing a single request.
Every lookup started by leaving the app. The business context people began with was gone by step two.
- Spot the record in Fusion
- Leave the app for the docs siteContext lost here
- Search for the right resource
- Scan an endpoint list by path
- Read properties and operations
- Build the request by hand
Repeated for every object a project touches.
I designed the path from business object to API request
The brief was to connect BOSS objects with Ask Oracle so people could find and use them without leaving Fusion.
I started from existing research insights and a review of Postman, Microsoft Graph Explorer and Google’s APIs Explorer. From there I designed the Ask Oracle universal BOSS object search, the business object list, the navigation between objects and endpoints, and the Try it section, over 3 months.
It had to live inside Fusion
It had to use Fusion’s own shell and patterns
A separate developer portal would have recreated the jump out of the app. So API context appears as a business object panel on pages people already use, with the same Find, List and Quick Filters patterns as the rest of Fusion.
Business objects change state and version
Endpoints can be active or inactive, objects ship in versions, and custom endpoints sit alongside the standard ones. So every endpoint shows its status, every object has a version switcher, and standard actions are kept apart from custom endpoints so people know which ones are guaranteed.
I organised the API around business objects, not endpoints
Both decisions came from the same idea: start where people already are.
Business-object-first search over an endpoint reference
A list of endpoint paths only helps once you already know the path. I made the business object the entry point: an Ask Oracle search across every BOSS object, narrowed by functional area, visibility and consumer, leading to an object page that groups its endpoints. What I gave up: one long reference page that experienced developers could scan top to bottom.
Before
- Get/
api/ boss/ data/ objects/ ora/ common/ v1/ tags - Post/
api/ boss/ data/ objects/ ora/ common/ v1/ tags/ $query - Get/
api/ boss/ data/ objects/ ora/ sales/ v1/ leads - Patch/
api/ boss/ data/ objects/ ora/ sales/ v1/ leads/ {leads_id}
After
People search for “leads”, not for a path. Type a name, tick a filter or remove a chip; every result is a business object with its endpoints one click away.
Read, copy and try on one page over a separate test workspace
Postman-style tools split reading an API from trying it. Following the pattern Google’s APIs Explorer uses beside its reference, I kept the request schema, response, code samples in four languages and Try it on the same endpoint page. What I gave up: the request configurability of a full API client.
Read, copy and try without leaving the page. Switch languages, then press Try it to see the response the request returns.
From a Fusion record to a tested request, without leaving the app
Status: Piloted
The business context people start with survives all the way to the request.
- Find the objectAsk Oracle search or the record’s own panel
- Open its APIEndpoints grouped, with status and version
- Read the endpointRequest, response and code in four languages
- Try itSee the real response before writing code
Outcome
"Try it section is making my life easier"
Developer working with Visual Builder studio
"This is much better organized now, instead of a fragmented part of the Oracle ecosystem, BOSS API documentation has found it's way in the Fusion application"
CX Infodev management
Before, a developer who started from a lead or a tag had to leave the app, work out whether the object used the older API style or BOSS, find the right version, scan a path list and build the request by hand. In the concept, they find the object through Ask Oracle or the record’s own panel, open its endpoints with status and version visible, read the request and response with code in four languages, and try it before writing a line of code.
The concept showed that API discovery doesn’t need a separate developer portal. Fusion already knows which business object a person is looking at, so the API can start there.