Part 3 of 12 in the Oracle EPM Cloud REST API series.
Every REST call starts with a URL, and once you can read one, you can predict most others without looking anything up. Oracle EPM Cloud builds its REST URLs from four consistent pieces.
| Component | What it is | Example |
|---|---|---|
| Server | Your specific Oracle EPM Cloud instance | https://epm-xyz.epm.us-phoenix-1.ocs.oraclecloud.com |
| Service | The context root for the module you are calling | HyperionPlanning |
| REST version | The version of the API being accessed | v3 |
| Resource | The specific object or action | applications/Vision/jobs |
Put together, a real, callable endpoint looks like this:
https://epm-xyz.epm.us-phoenix-1.ocs.oraclecloud.com/HyperionPlanning/rest/v3/applications/Vision/jobs
Read left to right, that URL says: on this Oracle EPM Cloud instance, using the Planning service, version 3 of the REST API, act on the jobs resource that belongs to the application named Vision.
Two details will save you some confusion when you start building your own calls.
The server address is never used by itself. Calling just https://epm-xyz.epm.us-phoenix-1.ocs.oraclecloud.com with nothing after it will fail every time. Every request needs the service context (HyperionPlanning, in this example) appended, or there is no valid resource for Oracle to find.
HyperionPlanning is not the only service name you will see. That context root is specific to Planning and Planning Modules. Every other Oracle EPM Cloud pillar exposes its REST APIs under its own service name: Financial Consolidation and Close (FCCS), Account Reconciliation (ARCS), Tax Reporting (TRCS), Enterprise Profitability and Cost Management (EPCM and PCMCS), and Enterprise Data Management (EDMCS) each have their own. Cross-product areas like migration, security, and user, group, and role management follow the same grammar too. The pattern of server, service, version, resource holds across all of them, so once URLs like this feel natural for Planning, reading a FCCS or ARCS endpoint takes no extra effort.
A quick way to build intuition: try mentally parsing a few more example resources against the same Planning service and version.
.../HyperionPlanning/rest/v3/applications/Vision/jobs/145
.../HyperionPlanning/rest/v3/applications/Vision/planningunits
.../HyperionPlanning/rest/v3/applications/Vision/variables
Same server, same service, same version, just a different resource at the end: a specific job by its ID, planning units, or user variables. That last segment is what changes as you move from one action to another, while the first three pieces usually stay fixed for the length of an entire script.
With the URL grammar down, the next piece is what you attach to that URL to actually make something happen: the HTTP verb.