Oracle Fusion REST API Multi-Language Data: SourceLanguage, Language, and the HCM Gap

Oracle Fusion Cloud supports multiple installed languages, and both FSCM and HCM have real, REST-exposed behavior around it — but they behave completely differently, and neither is documented anywhere as a practical guide. FSCM’s Product Information Management (PIM) resources expose a translatableAttributes child resource with a SourceLanguage/Language composite key that’s easy to get backwards — get it wrong and you can silently overwrite a translation in every language instead of the one you meant. HCM has no REST mechanism to request a response in a specific language at all, a real product gap Oracle has left open since 2020. Every search result on this topic today is either Oracle’s own per-endpoint reference page or one Support KB doc that has to walk through four separate methods (REST, SOAP, FBDI, Import Map) just to explain getting one field translated. This is the practical version.

All examples use an anonymized pod (acme.fa.us2.oraclecloud.com) and placeholder identifiers — swap in your own.

FSCM: the translatableAttributes child resource

A set of Product Information Management resources — catalog-verified: itemCategories, itemCatalogs, GTINRelationships, crossReferenceRelationships, tradingPartnerItemRelationships, relatedItemRelationships, itemRuleSets, spokeSystemItemRelationships, rulesImpactAnalysis — each expose a translatableAttributes child resource. Every language’s version of a translatable field (a category name, a description) lives as its own row in that child, not as extra columns on the parent.

curl -u integration.user \
  "https://acme.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/itemCategories/300000001234567/child/translatableAttributes"

A populated response has one row per language:

{
  "items": [
    { "CategoryId": 300000001234567, "CategoryName": "Fasteners", "Description": "Bolts and screws", "Language": "US", "SourceLanguage": "US" },
    { "CategoryId": 300000001234567, "CategoryName": "Fixations", "Description": "Boulons et vis", "Language": "FR", "SourceLanguage": "US" }
  ],
  "count": 2,
  "hasMore": false
}

To fetch or filter to one language, Language and SourceLanguage are both real queryable fields (=, !=, LIKE) — use q:

curl -u integration.user \
  "https://acme.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/itemCategories/300000001234567/child/translatableAttributes?q=Language=FR"

SourceLanguage vs Language — the field everyone gets backwards

The names read like synonyms, but they mean opposite things:

• Language is the language of this row — the language the CategoryName/Description values on this specific record are written in.
• SourceLanguage is the language the session that created the master record was running in — effectively which row is the “original,” not a translation target.

Creating a new French translation of an existing category means POSTing a new row to the child with Language: "FR" and SourceLanguage set to the language the base record was created under (commonly "US"), not the language you’re adding:

curl -u integration.user -X POST \
  -H 'Content-Type: application/json' \
  -d '{
    "CategoryId": 300000001234567,
    "CategoryName": "Fixations",
    "Description": "Boulons et vis",
    "Language": "FR",
    "SourceLanguage": "US"
  }' \
  "https://acme.fa.us2.oraclecloud.com/fscmRestApi/resources/11.13.18.05/itemCategories/300000001234567/child/translatableAttributes"

This isn’t a theoretical mix-up. A real, unanswered Cloud Customer Connect thread (“item description translation changes all languages instead of one - PIM”) describes exactly this: an update meant for one language’s item description ended up affecting every language’s value instead, because the request targeted the wrong side of the composite key. Oracle’s own Support KB Doc 2844829_1 (“Fusion PIM: Item Description Import in Multi Languages Using REST API, SOAP Service, FBDI and Import Map”) exists specifically because getting this right through REST alone isn’t self-evident from the reference docs — it has to walk through three other channels as alternatives.

Updating an existing translation is a PATCH to that specific row’s own child URL (.../child/translatableAttributes/{translatableAttributesUniqID}), same as any other child resource — not a POST, which creates a new language row instead of correcting an existing one.

HCM: there’s no REST language override

FSCM’s pattern doesn’t exist on the HCM side. Nothing in the catalog — not jobs, not positions, not grades, not departments — exposes a translatableAttributes-style child. That’s not a documentation gap, it reflects a real architectural difference: HCM REST responses come back in whatever language the calling session is running in, with no query parameter or header to request a different one.

A Cloud Customer Connect idea, “Support language selection in REST API for Oracle HCM Cloud” (Idea Lab – Integration Cloud, submitted January 2020), asks for exactly this — the submitter’s example is departmentsLov returning department names only in English regardless of a Canadian-French-speaking caller’s needs, with no language/culture parameter documented anywhere to fix it. As of this writing the idea’s status is still “Submitted” — it has not shipped.

What this means practically, since no third-party guide states it plainly: if you need HCM values (LOV names, descriptions) in more than one language via REST, there is no supported per-request override. Real workarounds people actually use:

• Call the API using an integration/service account whose own session language matches the language you need for that batch, if your architecture allows a session per target language.
• For genuine multi-language exports at scale, fall back to non-REST channels (HCM Data Loader or BI extracts), which do carry language-specific attribute sets that REST does not expose the same way.
• Don’t design an integration around “pass a language param” for HCM — confirm with /describe on the specific resource first (more on /describe) that there’s genuinely no language-related field before spending time on a workaround; a handful of resources carry legislation-specific Local* fields (for example workers’ LocalFirstName/LocalLastName/LocalDisplayName) that store a second name variant, but that’s a distinct feature from response-language selection and only exists on person-name data.

Checklist

• FSCM PIM child resources (itemCategories, itemCatalogs, GTINRelationships, crossReferenceRelationships, tradingPartnerItemRelationships, relatedItemRelationships, itemRuleSets, spokeSystemItemRelationships, rulesImpactAnalysis): use translatableAttributes, one row per language.
• Language = the language of this row. SourceLanguage = the language the master/original record was created in. Confusing them is the recurring real-world bug.
• Create a translation with POST (new Language row); correct one with PATCH to that row’s own child URL — POSTing again creates a duplicate row rather than fixing the existing one.
• HCM REST has no per-request language override today — it’s a known, unresolved gap (CCC Idea 520402), not something misconfigured on your side.

Where this fits with everything else

The SourceLanguage/Language composite key follows the same “extra dimension on a child resource” shape as descriptive flexfields — a child collection where one field (here Language, there __FLEX_Context) determines which row you’re looking at. Filtering translations by language uses the same q parameter syntax as everything else in the catalog, and updates are subject to the same ETag/If-Match concurrency rules as any other PATCH. For full request walkthroughs on FSCM resources generally, see the FSCM REST API guide; the endpoint catalog lists child resources for the top HCM and FSCM endpoints, including invoices and receivables credit memos.

---

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