Oracle HCM

This page records how composerID publishes into Oracle HCM: the vendor’s API posture, the publish target and field mapping, and the documentation each claim rests on. It is for anyone evaluating the connection or building against it. Oracle Fusion Cloud HCM is the worker and position system of record on the permanent-hiring channel, and holds contingent workers as a worker type alongside employees. Its REST surface (hcmRestApi) exposes positions, jobs, departments, locations and workers, plus job requisitions where Oracle Recruiting is licensed, with tenant-configured Descriptive Flexfields (DFFs) exposed as child resources. composerID publishes the decision as a Position through the positions resource, stamps the Intent ID into a DFF segment on that position (the positionsDFF child), and reads the eventual hire back from the workers resource and HCM change feeds.

Category: HRIS / HCM. Coverage status: Specification mapped. Vendor documentation: public developer portal.

Integration path

How composerID connects to this destination, at a glance.

Step	Detail
Authentication	OAuth 2.0 via OCI IAM identity domains: register a confidential application (JWT user assertion or client credentials for server-to-server) and mirror its identity as a Fusion user holding the HCM roles and data security the write needs.
composerID publishes	Position: POST /hcmRestApi/resources/{version}/positions
Intent ID lands on	`position` `positionsDFF.intentId`, written into the destination record
Back-sync	Webhooks and polling: some lifecycle events are pushed, the rest are read on a schedule.

Vendor documentation

Oracle Fusion Cloud HCM documentation

REST API for Oracle Fusion Cloud HCM (25C)

OCI IAM identity domains (OAuth clients for Fusion Applications)

API posture

Aspect	Detail
Authentication	OAuth 2.0 via OCI IAM identity domains: register a confidential application (JWT user assertion or client credentials for server-to-server) and mirror its identity as a Fusion user holding the HCM roles and data security the write needs; a token alone is not enough. HTTP Basic is accepted but fails once MFA is enforced, so treat OAuth as the production path.
Style	REST, JSON (ADF-based resources with child collections such as positionsDFF); offset/limit pagination with hasMore; q= filter syntax on top-level attributes. The same version string is used across resources; pin it rather than relying on the latest alias.
Base URL	https://{host}/hcmRestApi/resources/{version} (version string such as 11.13.18.05; HCM Data Loader remains the bulk path)
Webhooks	No plain webhook registry on the REST resources. Changes are exposed as HCM Atom feeds under hcmRestApi/atomservlet (employee newhire, empassignment, empupdate and similar) that a consumer polls, and as HCM business events consumed through Oracle Integration (OIC). Direct HTTP callbacks are indicative until confirmed at onboarding.
Events posture	Webhooks and polling
Rate limits	Not published by Oracle for HCM REST; requests are throttled per identity domain and return 429 on breach. Keep publishing transactional and use HCM Data Loader for volume. Any figure is indicative until confirmed at onboarding.
Objects	positions (+ positionsDFF child), jobs, departments, locations, grades, workers (workRelationships, assignments; employee and contingent worker types), recruitingJobRequisitions (Oracle Recruiting, read documented), HCM Atom feeds

Publish target and field mapping

Each object below pairs the canonical intent fields with the destination’s own fields and operations. The mapping is indicative until it is confirmed against a tenant at onboarding.

Position

Create the headcount to hire against

Mapping	Detail
Canonical to destination	role_title -> Name, PositionCode, BusinessUnitId, DepartmentId, JobId, LocationId, EffectiveStartDate, HeadCount, FullTimeEquivalent, HiringStatus
Target	POST /hcmRestApi/resources/{version}/positions
Requirement	Required
Notes	PositionCode is the tenant’s business key (usually auto-numbered, 30 characters) and is left to tenant policy, not overloaded with the Intent ID. Job, department, location and business unit must already exist; preflight resolves names to their IDs.

Intent ID correlation

Carry the Intent ID

Mapping	Detail
Canonical to destination	intent_id -> positionsDFF.<segment> (tenant-named Descriptive Flexfield segment on the position, proposed intentId)
Target	positionsDFF child resource of positions
Requirement	Required
Notes	DFF segments are tenant-configured and surface in REST under the segment’s API name with a __FLEX_Context attribute; agree the segment (proposed intentId, text) at onboarding. The value is read back by GET on the positionsDFF child. Server-side q= filtering on a DFF attribute and the position deep link are illustrative and indicative until confirmed at onboarding.

Job Requisition (Oracle Recruiting)

Open the requisition where Recruiting is licensed

Mapping	Detail
Canonical to destination	role_title, PositionId, hiring_manager, openings, location
Target	recruitingJobRequisitions resource
Requirement	Tenant (Recruiting licensed)
Notes	Read access is documented; requisition creation through REST is indicative until confirmed at onboarding, with HCM Data Loader as the fallback. Linking the requisition to the stamped Position carries the correlation without a second stamp.

Hire / assignment back-sync

Close the loop

Mapping	Detail
Canonical to destination	worker filled into the Position (PositionId on the assignment), start date, worker type
Target	GET workers + HCM Atom feeds (employee newhire, empassignment)
Requirement	Read scope only
Notes	Poll the Atom feeds or consume the business event via OIC; the assignment’s PositionId ties the hire back to the stamped position and so to the Intent ID. Confirm Atom feed support for the tenant, since Oracle’s forward path is business events.

Auth is per identity domain: register the confidential app in OCI IAM and mirror its Client ID as a Fusion user with HCM roles and data security for the business units it will write to. Version strings matter (resources exist in several versions) and the pod host shape differs between older and newer tenants, so the host and version are taken from the tenant. DFF segments are tenant-configured, so the Intent ID segment on positionsDFF is agreed per tenant and its REST attribute name follows from the segment’s API name; PositionCode numbering follows tenant policy. Oracle Recruiting is a separately licensed module: confirm it, and REST create support for requisitions, before planning the requisition step. Whether the tenant still runs Atom feeds or has moved to business events through OIC decides the read-back path, and the position deep link objType is confirmed from the tenant’s Deep Links work area. Contingent workers are a worker type in HCM, not a sourcing workflow: the VMS remains the sourcing destination on that channel.

Next steps

How composerID connects

The five ways composerID reaches a destination, and the minimum a destination must offer.

Publishing

Plan, preflight and publish: how a decision becomes a valid record in a destination.

All destinations

Every destination composerID documents, with its category and coverage status.

⌘I

Get started

Concepts

Guides

Destinations

Upstream connectors

API reference

Endpoints

Manuscript API (Triage)

Manuscript endpoints

Resources

Integration path

Vendor documentation

Oracle Fusion Cloud HCM documentation

REST API for Oracle Fusion Cloud HCM (25C)

OCI IAM identity domains (OAuth clients for Fusion Applications)

API posture

Publish target and field mapping

Next steps

How composerID connects

Publishing

All destinations

​Integration path

​Vendor documentation

Oracle Fusion Cloud HCM documentation

REST API for Oracle Fusion Cloud HCM (25C)

OCI IAM identity domains (OAuth clients for Fusion Applications)

​API posture

​Publish target and field mapping

​Next steps

How composerID connects

Publishing

All destinations

Integration path

Vendor documentation

API posture

Publish target and field mapping

Next steps