> ## Documentation Index
> Fetch the complete documentation index at: https://www.composer.id/llms.txt
> Use this file to discover all available pages before exploring further.
# Oracle HCM
> Oracle HCM (HRIS / HCM): the API posture, publish target and field mapping composerID publishes a decision reference through.
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
## 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.
| 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. |
| Mapping | Detail |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Canonical to destination | intent\_id -> positionsDFF.\ (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. |
| 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. |
| 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
The five ways composerID reaches a destination, and the minimum a destination must offer.
Plan, preflight and publish: how a decision becomes a valid record in a destination.
Every destination composerID documents, with its category and coverage status.