Oracle Fusion REST API: recruitingCEJobRequisitions and recruitingCEJobRequisitionDetails

If you’re building or integrating an external career site against Oracle Recruiting Cloud, you’ve probably landed on two REST resources with almost-identical names: recruitingCEJobRequisitions and recruitingCEJobRequisitionDetails. “CE” stands for Candidate Experience — these are the resources behind the public job-search and job-detail pages, not the internal recruiter-facing requisition object. They’re easy to confuse with each other, and most guides that mention Oracle Fusion REST finders don’t actually apply to them, which causes real confusion. Here’s what each resource does, grounded in the fields OPAL’s own indexed catalog shows for them.

Two different jobs, two different resources

recruitingCEJobRequisitions is the search/list resource — it’s what powers a career site’s job-search results page: “show me open roles matching this keyword, in this location, posted after this date.” A single GET returns a page of lightweight requisition summaries.

recruitingCEJobRequisitionDetails is the detail resource — it’s what powers the individual job-posting page once a candidate clicks through: the full external description, qualifications, responsibilities, hiring-manager info, and the apply-related flags. Its own catalog summary even says “preview mode,” which lines up with Oracle Recruiting Cloud’s requisition-preview workflow for drafts.

GET /hcmRestApi/resources/{version}/recruitingCEJobRequisitions
GET /hcmRestApi/resources/{version}/recruitingCEJobRequisitions/{id}
GET /hcmRestApi/resources/{version}/recruitingCEJobRequisitionDetails
GET /hcmRestApi/resources/{version}/recruitingCEJobRequisitionDetails/{id}

Both are GET-only in Oracle’s REST API — there’s no POST/PATCH/DELETE on either, which makes sense for a public-facing search surface: candidates read job postings, they don’t write to them over this API.

SiteNumber — the parameter most guides skip

If your organization runs more than one Oracle Recruiting Cloud career site — separate brands, regions, or business units each with their own public job board — SiteNumber is the field that scopes a search to one specific site. It’s a real, queryable q field on recruitingCEJobRequisitions:

GET .../recruitingCEJobRequisitions?q=SiteNumber=CSS_1;Keyword=Engineer

Miss SiteNumber on a multi-site tenant and you’ll pull requisitions from every career site at once — not wrong, exactly, but not what a single branded job board wants to show.

The query fields that actually power a career site’s search box

recruitingCEJobRequisitions’ queryable fields read like a search-UI spec, because that’s exactly what they back:

• Free-text search: Keyword, CorrectedKeyword (spell-corrected version), ExecuteSpellCheckFlag, BotQRShortCode — yes, there’s a flag specifically for chatbot/voice-assistant query shortcuts.
• Geo search: Location, LocationId, Latitude, Longitude, Radius, RadiusUnit — a “jobs within N miles of this point” radius search.
• Date filtering: PostingStartDate, PostingEndDate.
• Candidate context: CandidateNumber, SearchId (ties a request back to a saved/previous search session).
• Flags: HotJobFlag, JobFamilyId, OrganizationId, RequisitionId.
• Pagination: Limit, Offset — standard REST pagination, separate from the q-filter fields.
• Faceted search: SelectedCategoriesFacet, SelectedLocationsFacet, SelectedOrganizationsFacet, SelectedPostingDatesFacet, SelectedTitlesFacet, SelectedWorkLocationsFacet, SelectedWorkplaceTypesFacet, SelectedFlexFieldsFacets, LastSelectedFacet — one field per facet category a career site’s filter sidebar typically shows.

Note the operators: in OPAL’s indexed catalog, every field on this resource supports only = and != — no >, <, or LIKE-style partial matching at the q-parameter level. Keyword relevance and fuzzy matching happen inside Oracle’s own search engine behind Keyword/CorrectedKeyword, not through richer q operators.

Finders don’t apply here — and that’s worth knowing before you go looking

A lot of Oracle Fusion REST resources expose named finders (finder=ByEmployeeNumber, finder=findByDates, and so on), and if you’ve worked with other HCM resources, it’s natural to go looking for one here — something like finder=findReqs. OPAL’s indexed catalog shows no finders defined on either recruitingCEJobRequisitions or recruitingCEJobRequisitionDetails — both resources expose only the base collection GET, the GET /{id} lookup, and q-parameter filtering on the fields above. If you’re searching for a named-finder answer for these two resources specifically, the fields-and-q approach above is the actual mechanism, not a finder.

Child resources — where the rest of the posting lives

Neither resource is flat. recruitingCEJobRequisitions exposes child resources that mirror a career site’s filter sidebar one-for-one: categoriesFacet, flexFieldsFacet, locationsFacet, organizationsFacet, postingDatesFacet, titlesFacet, workLocationsFacet, workplaceTypesFacet, plus requisitionList and requisitionLocationsCoordinates for mapping multiple work locations.

recruitingCEJobRequisitionDetails exposes the content that fills out a job-detail page: media (images/video attached to the posting), skills, workLocation, otherWorkLocations, secondaryLocations, primaryLocationCoordinates, and requisitionFlexFields for any descriptive flexfields a customer has added to the requisition. Pull them in one round trip with expand rather than chaining separate requests per child.

Two related, narrower resources

• recruitingCEJobRequisitionDetailsPreviews — a preview variant of the details resource, for viewing a requisition’s candidate-facing content before it’s posted live.
• recruitingCEJobRequisitionsCoordinates — geographic coordinates for requisitions, split out as its own resource so a career site’s map view can fetch just the lat/long data without pulling full requisition payloads.

A worked search-to-detail flow

A typical career-site integration does two calls: search, then fetch the one the candidate clicked.

# 1. Search a specific career site for open engineering roles, paginated
GET .../recruitingCEJobRequisitions?q=SiteNumber=CSS_1;Keyword=Engineer;HotJobFlag=true&limit=20&offset=0

# 2. Candidate clicks requisition 300000123456789 — pull full detail content
GET .../recruitingCEJobRequisitionDetails/300000123456789?expand=media,skills,workLocation

The search call stays lightweight (summary fields only); the detail call is the one worth expand-ing, since that’s where the long-form content and media live.

Summary

recruitingCEJobRequisitions is the career-site search resource — SiteNumber for multi-site scoping, Keyword/geo/date fields for the search box, facet child resources for the filter sidebar. recruitingCEJobRequisitionDetails is the detail resource for a single posting’s full content, with its own set of child resources for media, skills, and location data. Both are read-only, both filter with =/!= on q fields rather than named finders, and both are indexed — along with their Previews and Coordinates siblings — in OPAL’s full Oracle Fusion REST API catalog, searchable offline without a live Fusion instance.