Oracle Fusion REST API Absence Management: The Approval-Bypass Gotcha

Creating an absence through the Oracle Fusion UI routes it through the approval workflow automatically — a manager gets a notification, the request sits as Pending Approval until they act on it. Creating the same absence through the REST API often doesn’t. The record saves, the response comes back 200, and the absence is already sitting at Approved with no workflow notification ever sent. This isn’t a one-off bug report — it’s recurring enough that Oracle has published more than one Support KB article about it, and Cloud Customer Connect has open threads spanning several years asking the same question. This guide covers the base CRUD pattern for /absences, the fields that reveal whether approval actually ran, and the other REST-specific quirks (silently overridden durations, DFF/attachment child resources) that trip people up.

All examples use an anonymized pod (acme.fa.us2.oraclecloud.com) and placeholder identifiers — swap in your own. Field names below are taken directly from the live /absences resource metadata (79 queryable fields, catalog-verified), not guessed from documentation.

The base resource

/absences is a standard resource — no dedicated finders are defined on it (the finders list in /describe comes back empty), so every targeted lookup goes through q:

GET    /hcmRestApi/resources/11.13.18.05/absences
GET    /hcmRestApi/resources/11.13.18.05/absences/{personAbsenceEntryId}
POST   /hcmRestApi/resources/11.13.18.05/absences
PATCH  /hcmRestApi/resources/11.13.18.05/absences/{personAbsenceEntryId}
DELETE /hcmRestApi/resources/11.13.18.05/absences/{personAbsenceEntryId}

The resource key is personAbsenceEntryId, not the worker’s personId — a single worker has one absence entry per absence record, not one per career.

Querying a worker’s absences

curl -u 'integration.user@example.com:YourPassword' \
  'https://acme.fa.us2.oraclecloud.com/hcmRestApi/resources/11.13.18.05/absences?q=personNumber=100001&orderBy=startDate:desc'

Useful q fields for filtering: personNumber, personId, absenceType, absenceTypeId, absenceStatusCd, approvalStatusCd, startDate, endDate, processingStatus. absenceDispStatus (the display status code) and its human-readable pair absenceDispStatusMeaning are response-only — read them, don’t filter on them directly if absenceStatusCd gives you the same answer more reliably.

Creating an absence

curl -u 'integration.user@example.com:YourPassword' -X POST \
  -H 'Content-Type: application/vnd.oracle.adf.resourceitem+json' \
  -d '{
    "personNumber": "100001",
    "absenceType": "Vacation",
    "startDate": "2026-10-06",
    "endDate": "2026-10-10",
    "absenceReason": "Personal"
  }' \
  'https://acme.fa.us2.oraclecloud.com/hcmRestApi/resources/11.13.18.05/absences'

The exact set of required fields depends on how the worker’s absence plan is configured (some plans require absenceTypeReasonId instead of a free-text reason, some enforce specific duration attributes) — check /describe against your own instance before assuming this exact shape works for every plan. What’s consistent across configurations is the gotcha below.

The approval-bypass gotcha

A Cloud Customer Connect thread from November 2025 lays out the exact symptom: an absence created via POST /absences saves successfully but comes back with an approval status that skips Pending Approval entirely, going straight to Approved — no workflow task, no manager notification, nothing for the manager to act on. It’s an open thread with no accepted resolution. Oracle has separately published Support KB articles under titles like “HCM REST API How to trigger the Approval Work Flow when creating the absence records using REST API” and a companion one for the update path — the existence of dedicated KB articles for this exact behavior (rather than it being answered inline in the REST API documentation) is itself a signal this isn’t obvious or self-evidently configuration-driven.

Two fields tell you what actually happened after a create or update, and you should check them rather than assume the UI’s approval behavior carried over:

• approvalStatusCd — the underlying approval status code on the absence record.
• absenceDispStatus / absenceDispStatusMeaning — the display status and its human-readable label (this is what a manager would see in the UI if the record needed their attention).

If an integration creates absences on behalf of workers, don’t treat a 200/201 response as “the request is now pending approval.” Read the record back immediately after creating it and check whether absenceDispStatusMeaning actually says something like “Pending Approval” — if it says “Approved” and nobody approved anything, the workflow was bypassed, and any downstream process relying on manager sign-off (payroll cutoffs, coverage planning) needs to know that before it acts on the record as if it had been reviewed.

This is a documented, reported behavior, not something this post can hand you a guaranteed fix for — root cause reports point at absence-plan and approval-rule configuration in different cases, not a single universal switch. Treat the two fields above as your detection mechanism, and involve whoever owns the absence-plan setup in your Fusion instance if the bypass is unwanted.

Silently overridden dates and duration

A separate, also-unresolved Customer Connect thread (April 2025) reports a related but distinct problem: when a worker has a resource exception defined (a calendar exception — a scheduled non-working period), creating an absence via REST for that same window can come back with the requested startDate, endDate, and duration silently overridden with values pulled from the resource exception instead of the values actually submitted. The request doesn’t error — it just doesn’t save what you sent. If your integration does date math based on the response, compare the returned startDate/endDate/duration against what you posted rather than assuming an echo.

Balance and plan enrollment: not the same resource

Several Customer Connect threads ask whether there’s a REST API to update an absence balance or enroll a worker in an absence plan directly — as distinct from creating an absence entry. /absences itself doesn’t expose balance or enrollment as writable fields on the entry; the closest catalog-confirmed connections are the absenceEntitlements and absenceEntitlementUniquePlans child resources, which describe entitlement and plan data attached to an absence record rather than a general balance-adjustment or enrollment endpoint. If your use case is adjusting balances or managing plan enrollment outside the context of a specific absence entry, verify against your own instance’s /describe output before assuming /absences is the right resource at all — several forum threads on this specific question remain open without a confirmed REST path.

Other child resources worth knowing

/absences carries nine child resources: absenceAttachments, absenceEntitlementUniquePlans, absenceEntitlements, absenceEntryCertifications, absenceEntryDetails, absenceMaternity, absenceRecordingDFF, absenceRecordingsDDF, and linkedAbsences. The two flexfield children — absenceRecordingDFF (descriptive flexfield) and absenceRecordingsDDF (a second, differently-scoped descriptive flexfield context) — follow the same __FLEX_Context pattern covered in the descriptive flexfields guide; don’t assume a single flat set of custom fields without checking /describe for whichever context is active on your instance.

Common errors

• 400 on POST with no clear field named — check absenceTypeReasonId vs. a free-text absenceReason; some absence-type configurations require the ID form and reject free text, and the error message doesn’t always name the field clearly.
• Custom or restricted roles causing REST-specific failures — a request that works fine through the UI can 400 or 403 through REST when the calling user has a custom role, since the two paths don’t always resolve security identically. If a request errors only via REST and only for certain users, compare the calling user’s role setup before assuming it’s a payload problem.
• Assuming the response echoes your input — as covered above, always re-read startDate/endDate/duration/absenceDispStatusMeaning from the response (or a follow-up GET) rather than trusting that what you sent is what got saved.

Related reading

For the general date-effective pattern most HCM objects (including absences’ effectiveStartDate/effectiveEndDate fields) follow, see the effective dates guide. For q filter syntax in more depth, see the q parameter guide. The full /absences field list, child resources, and operations are browsable offline in OPAL’s absences reference page, alongside the rest of the endpoint catalog.

---

This post is part of our complete Oracle HCM API guide — auth, base URLs, q filters, finders, and key endpoints in one place.