Find Every Oracle Fusion HCM API Field with OPAL: Blood Type Example

Oracle Fusion REST APIs are huge. A single business field can appear in many resources, child resources, request bodies, response bodies, query fields, and LOV-style objects.

That is why searching only the Oracle documentation page by page is slow. You may find one endpoint, but miss ten others. You may use a response field when the field is not writable there. Or you may try a q filter on a resource where the field is visible in the response but not actually queryable.

This is where OPAL becomes useful.

OPAL can search the full API metadata, not only endpoint names. It can search inside:

• parameters
• queryable fields
• response fields
• request body fields

In this example, we searched the HCM API metadata for:

bloodtype

The result was not one endpoint. OPAL found 93 endpoints where the field appears across HCM.

---

Why this matters

When developers ask, “Which Oracle Fusion API has Blood Type?”, the real answer is not just one URL.

There are different questions behind that one question:

• Where can I read blood type from a worker?
• Where can I filter by blood type?
• Where can I create or update blood type?
• Is the field available on contacts too?
• Is it returned through embedded person objects in employment, position, or recruiting APIs?
• Which endpoint should I use for a real integration?

A normal endpoint search usually answers only the first question. OPAL helps answer all of them.

---

What OPAL found for BloodType

The OPAL metadata search found BloodType in these HCM areas:

Area	Endpoint count	What it means
personBiographicalInfo	4	Main direct resource for reading, creating, and updating person biographical information
personalDetails	2	Read-oriented personal details resource
hcmContacts	8	Contact records where BloodType appears in contact/person data
workers root	6	Worker root endpoints where BloodType appears in worker payloads
workers child resources	43	Worker child resources where BloodType appears in metadata, parameters, or query fields
Employment person LOV resources	8	Employment flows that expose embedded person LOV data
Position person LOV resources	8	Position/incumbent flows that expose embedded person LOV data
Recruiting job offer person resources	4	Recruiting job offer flows that expose person data

This changes how you think about the API. BloodType is not only a field on /workers. It appears in multiple HCM contexts.

---

The most important endpoint: personBiographicalInfo

For direct work with BloodType, the cleanest resource is usually:

/hcmRestApi/resources/latest/personBiographicalInfo

OPAL found BloodType in this resource in:

q_fields
response_fields
request_body

That means the field can be used for searching, returned in the response, and used in create/update payloads where the operation is supported.

Typical read pattern:

GET /hcmRestApi/resources/latest/personBiographicalInfo?onlyData=true&q=PersonId=<PERSON_ID>

Typical filter pattern:

GET /hcmRestApi/resources/latest/personBiographicalInfo?onlyData=true&q=BloodType='O+'

Typical update pattern after you identify the biographical record:

PATCH /hcmRestApi/resources/latest/personBiographicalInfo/{personBiographicalInfo_Id}

Example body:

{
  "BloodType": "O+"
}

The exact required identifiers depend on the record you are updating, but the important point is this: if your goal is to maintain BloodType, do not assume /workers is the best write endpoint just because it returns the field.

---

Reading BloodType from Workers

The Workers API can return BloodType at the root level.

Example:

GET /hcmRestApi/resources/latest/workers?onlyData=true&q=PersonNumber='100001'

You may see a response shape like:

{
  "PersonId": "300000008491568",
  "PersonNumber": "100001",
  "BloodType": "O+"
}

This is useful when your integration already starts from workers and you only need to display or inspect the value.

But Workers is a broad resource. It includes person, employment, names, emails, work relationships, assignments, managers, and many child objects. For quick discovery, it is great. For a focused update, use the more specific resource when possible.

---

Why OPAL marks where the field was found

In the OPAL result, each endpoint shows where the field was found:

parameters
q_fields
response_fields
request_body

These labels matter.

Found in	Meaning
parameters	The field appears in endpoint parameter metadata
q_fields	The field is queryable using q on that endpoint
response_fields	The field is returned in the response payload
request_body	The field can be sent in create/update payloads

This prevents a common Oracle Fusion REST mistake: seeing a field in a response and assuming it can also be filtered or patched on the same endpoint.

Example:

BloodType in response_fields

does not automatically mean:

BloodType is valid in q
BloodType is valid in PATCH body

OPAL helps you see the difference before you waste time testing unsupported calls.

---

How to use OPAL to investigate any field

Open OPAL and search for the field name, for example:

bloodtype

Instead of only matching endpoint names, OPAL searches the metadata behind the API. That means it can find fields inside query definitions, response schemas, and request bodies.

A good workflow is:

1. Search for the field name in OPAL.
2. Review which resources contain the field.
3. Check the Found In column.
4. Pick the right endpoint based on your goal.
5. Test the smallest GET call first.
6. Add q, expand, or body payload only after confirming the field is supported there.

This gives you a faster route from “I need this field” to “I know the right API operation”.

---

Choosing the right endpoint

For BloodType, use this simple decision path:

Goal	Recommended endpoint
Display BloodType while already reading workers	/workers
Search people by BloodType	/personBiographicalInfo if available in q_fields
Create or update BloodType	/personBiographicalInfo
Read personal details only	/personalDetails
Investigate contacts	/hcmContacts
Understand where BloodType appears indirectly	Employment, Positions, Recruiting person LOV resources

This is the key lesson: the same field can appear in multiple resources, but the best endpoint depends on what you are trying to do.

---

Example OPAL flow idea

You can build a small OPAL flow for field discovery validation:

Step 1: Search metadata in OPAL

Search:

bloodtype

Review the endpoint list and choose personBiographicalInfo for direct maintenance.

Step 2: Read a worker sample

GET /hcmRestApi/resources/latest/workers?onlyData=true&q=PersonNumber='100001'

Confirm the worker has a PersonId and current BloodType value.

Step 3: Read biographical info

GET /hcmRestApi/resources/latest/personBiographicalInfo?onlyData=true&q=PersonId=<PERSON_ID>

Confirm the biographical record that stores the BloodType value.

Step 4: Test update only on the focused endpoint

PATCH /hcmRestApi/resources/latest/personBiographicalInfo/{personBiographicalInfo_Id}

Body:

{
  "BloodType": "O+"
}

This flow is safer than guessing from the worker payload alone.

---

Common mistakes this avoids

1. Searching only endpoint names

If you search only for endpoint names, you may miss fields that exist inside the schema.

OPAL searches deeper than endpoint titles.

2. Using Workers for everything

Workers is useful, but it is not always the best update resource.

For BloodType, personBiographicalInfo is the cleaner direct resource.

3. Confusing response fields with writable fields

A field returned in the response is not always accepted in PATCH or POST.

Check whether OPAL found it in request_body.

4. Confusing response fields with query fields

A field returned in the response is not always queryable.

Check whether OPAL found it in q_fields.

---

Why this shows the power of OPAL

Oracle Fusion APIs are not small. HCM alone can contain thousands of endpoints and child resources. The hard part is not only calling an endpoint. The hard part is knowing which endpoint should be called.

OPAL helps because it lets you search the full API surface by field name.

In this BloodType example, OPAL showed:

• The field exists across 93 HCM endpoints.
• The direct read/write resource is personBiographicalInfo.
• personalDetails is useful for reading personal data.
• workers returns BloodType but is not always the best write target.
• Contacts, employment, position, and recruiting resources may expose the same field through embedded person data.

That is the difference between testing APIs randomly and working from the metadata.

---

Final recommendation

When you need a field in Oracle Fusion, do not start by guessing the endpoint.

Start with OPAL field search.

Search the field name, check where it appears, compare q_fields, response_fields, and request_body, then choose the endpoint that matches your real operation.

For BloodType in HCM, start with:

/personBiographicalInfo

Use /workers when you need broad worker context, but use the dedicated biographical resource when you need a focused read or update.

Download OPAL here:

https://opalapi.dev

---

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