All topics
33 / 60
Integrationbeginner

Oracle Fusion REST APIs Fundamentals

Understand the structure, authentication, and common patterns of Fusion Cloud REST APIs

Fusion exposes nearly everything through REST. EBS had no native REST layer at all, so this is genuinely new rather than renamed.

Fusion REST APIs are like a well-organized library's online catalog system: instead of needing to walk into the archive room yourself (direct database access), you query a standardized public interface (the API) that lets you search, filter, and request exactly the books (records) and their related materials (expanded child resources) you need.

Key Concepts

1
The APIs are grouped by product family and versioned.
    /fscmRestApi/resources/11.13.18.05/invoices      SCM, financials
    /hcmRestApi/resources/11.13.18.05/workers        HCM
    /crmRestApi/resources/11.13.18.05/accounts       CX
2
The version in the path is what protects an integration from the quarterly update cycle. Pin to a version and the contract holds.
3
Standard verbs, with Fusion using PATCH rather than PUT.
    GET     retrieve
    POST    create
    PATCH   update the fields you send
    DELETE  remove
4
PATCH sends only the attributes that change. PUT would replace the whole resource, and on a Fusion object with dozens of fields that means sending everything back correctly or losing what you omitted.
PATCHPUT
5
Query parameters do most of the work.
    GET /invoices?q=SupplierId=1042;InvoiceAmount>10000
                 &orderBy=InvoiceDate:desc
                 &limit=50&offset=100
                 &fields=InvoiceNumber,InvoiceAmount
                 &expand=invoiceLines
6
    q         filter -- semicolon is AND
    orderBy   sort
    limit / offset   pagination
    fields    return only these, rather than everything
    expand    include child resources in the same call
7
expand is the one that matters for performance. Without it, fetching 500 invoices and their lines is 501 calls. With it, the lines come back inside the invoice payload.
expand
8
fields matters for the same reason. A Fusion resource returns a large payload by default, most of which an integration ignores.
fields
9
Discovery through describe.
    GET /invoices/describe
describe
10
Returns the resource's metadata: every field, every child resource, every operation. That includes custom fields added through Application Composer, which is why you do not need separate documentation each time somebody extends an object.
11
Authentication. Basic auth with a username and password for simple cases; OAuth 2.0 for production.
12
OAuth is the recommendation because a token is scoped and expires, whereas a password embedded in an integration is a standing credential that has to be rotated by hand and usually is not.
13
The practical caution. REST calls are rate-limited and each one costs a round trip. For a few hundred records they are the right tool. For a conversion of fifty thousand, they are not — that is what FBDI and HDL exist for.
14
What the interviewer is probing.1. "How do you authenticate to a Fusion REST API?" Probing: the practical starting point. Stalls: "A password." Moves up: basic authentication for simple cases, OAuth with JWT for anything production, using a dedicated integration user with least privilege.
15
2. "How do you avoid fetching more than you need?" Probing: the efficiency point. Stalls: "You cannot." Moves up: the fields parameter to select attributes, q for filtering, limit and offset for paging, and expand only where you need children.
16
3. "What is the rate consideration?" Probing: the operational reality. Stalls: "None." Moves up: SaaS pods throttle, so a loop making one call per record will be slow and may be blocked — bulk mechanisms exist for volume.
17
4. "When is REST the wrong tool?" Probing: judgement. Stalls: "Never." Moves up: for mass data loads — FBDI or HDL handle tens of thousands of records where REST would take hours.
Use cases:rest-apifusion-integrationoauthpagination