Using Postman with Oracle Fusion Cloud REST APIs (and the Missing Collection Problem)
Search for “Oracle Fusion Postman collection” and you’ll find OCI collections, login-gated support notes, and forum threads asking the same question you are. Here’s the situation as of 2026: Oracle publishes an official Postman workspace for OCI (infrastructure), but there is no official Postman collection for Fusion Applications — not for HCM, not for Financials, not for SCM. If you want to call Oracle Fusion Cloud REST APIs from Postman, you set it up yourself.
That setup is not hard, but there are three or four gotchas that cost people an afternoon each. This guide walks through all of them, then covers your realistic options for the missing-collection problem. Examples use an anonymized pod (acme.fa.us2.oraclecloud.com) and placeholder users ([email protected]) — swap in your own.
Step 1: An environment, not hardcoded URLs
Create a Postman environment with three variables so requests survive the move from test pod to production pod:
| Variable | Example value |
|---|---|
base_url | https://acme.fa.us2.oraclecloud.com |
hcm_api | {{base_url}}/hcmRestApi/resources/11.13.18.05 |
fscm_api | {{base_url}}/fscmRestApi/resources/11.13.18.05 |
11.13.18.05 is the stable REST resource version — it has been constant for years and pinning it keeps requests reproducible. Your first request is then:
GET {{hcm_api}}/workers?limit=5
Step 2: Basic Auth (development)
In the request’s Authorization tab, pick Basic Auth and enter the integration user’s credentials. Postman base64-encodes the header for you. This is fine for development and testing against a non-production pod.
Two things to know before it bites:
- The credential resolves to a Fusion user, and that user’s roles decide what you can see. A
401means bad credentials; a403means the user is authenticated but lacks the duty role for that resource. They are different tickets. - Pod password-rotation policies apply to integration users too. If a collection that worked last month suddenly returns
401, check password expiry before anything else.
Step 3: OAuth 2.0 (production-grade)
For anything long-lived, use OAuth 2.0 against your IDCS/IAM identity domain. In Postman’s Authorization tab choose OAuth 2.0 with the Password Credentials grant (Fusion’s standard user-assertion pattern for server-to-server integrations):
| Postman field | Value |
|---|---|
| Access Token URL | https://idcs-a1b2c3.identity.oraclecloud.com/oauth2/v1/token |
| Client ID / Secret | From your confidential app registration in IDCS |
| Username / Password | The integration user |
| Scope | The Fusion resource app scope, e.g. urn:opc:resource:consumer::all |
The token endpoint lives on the identity domain hostname, not the Fusion pod URL — pointing the token request at acme.fa.us2.oraclecloud.com is the most common OAuth-in-Postman mistake. Full flow details are in our authentication guide.
Step 4: The REST-Framework-Version header
This is the gotcha that generates the most confusing failures. Oracle’s REST framework has versions 1 through 9, and the default is version 1 unless you say otherwise. Modern q syntax, framework v3+ pagination of expanded children, and several newer behaviors need a higher version:
REST-Framework-Version: 4
Add it in the Headers tab — or better, at the collection level so every request inherits it. The symptom of forgetting it: a q filter that uses and/or RowMatch syntax returns a 400 that looks like a syntax error, because version 1 only understands the old query-by-example syntax.
Step 5: A real q and finder request
With auth and headers in place, these two patterns cover most exploration. A filtered collection:
GET {{hcm_api}}/workers?q=PersonNumber='100001'&fields=PersonId,PersonNumber&onlyData=true
Use Postman’s Params tab and let it URL-encode the q value — encoding the expression twice by pasting a pre-encoded string into the URL bar is the classic silent-empty-results bug. And a finder:
GET {{hcm_api}}/workers?finder=findByPersonId;PersonId=300000001234567
Note the semicolon between finder name and bind variable — it is not a second query parameter.
The missing collection problem, honestly
So Postman works. The real friction starts when you ask: which of the thousands of Fusion endpoints do I call, and what fields does it support? Without an official collection you have three options:
Build your own collection. Import requests one at a time as you discover endpoints in Oracle’s docs. This is what most teams do, and it works — but the collection only ever contains what you’ve already found, and q fields, finders, and child resources still live in browser tabs on docs.oracle.com. Oracle’s OpenAPI spec files are technically importable into Postman, but the HCM spec alone is a 200MB JSON file with 4,700+ paths — Postman is not built to ingest that.
Use Oracle’s docs as the index. Fine for a handful of known endpoints; painful the moment you’re asking “which resource has a field like X?” — the docs are organized alphabetically by resource, not searchable by field.
Use a purpose-built catalog alongside Postman. This is the gap OPAL was built for: it bundles the full Fusion catalog — 59,000+ HCM, FSCM, and BPM endpoints — indexed and searchable offline by name, parameter, or description. Every endpoint page shows its q fields with operators, finders with bind variables, and child resources before you send anything, and the Q Builder and Finder Builder construct the exact query strings from this guide visually. A crawlable slice of that catalog is free to browse in our endpoint reference — for example, workers with its 307 queryable fields.
Postman and OPAL are complements, not competitors: Postman is a general-purpose HTTP client with team workspaces and test scripting; OPAL knows what’s in the Fusion API surface. Plenty of people find the endpoint and field names in OPAL, then keep their team’s shared requests in Postman.
Quick reference: the whole setup
| Setting | Where in Postman | Value |
|---|---|---|
| Base URL | Environment variable | https://<pod>.oraclecloud.com/hcmRestApi/resources/11.13.18.05 |
| Auth (dev) | Authorization tab | Basic Auth, integration user |
| Auth (prod) | Authorization tab | OAuth 2.0, token URL on the IDCS domain |
| Framework version | Collection-level header | REST-Framework-Version: 4 |
| Content type (writes) | Headers | Content-Type: application/json |
| q filters | Params tab | Let Postman encode once |
This post is part of our complete Oracle Fusion API guide — pillars, base URLs, authentication, q filters, finders, and common errors in one place.