Custom fields missing in Onboarding API response after BTP extension

HCM SAP SuccessFactors
, , , , , , , ,
1

We deployed custom fields to the Onboarding object using SAP BTP extensibility wizard two weeks ago. Fields appear correctly in the UI and can be populated during onboarding workflows. However, when querying via OData API, these custom fields don’t appear in the response payload.

API call:


GET /odata/v2/OnboardingCandidateInfo?$select=firstName,lastName,custom_division,custom_costcenter

Response only includes firstName and lastName - the custom fields are completely missing. I’ve checked the BTP extensibility configuration and fields are marked as ‘API Enabled’. Is there a metadata refresh needed after deploying BTP extensions? Also wondering if $select parameter handling changed for custom fields in H2 2023.

2

The API metadata cache is definitely the issue here. After deploying BTP extensions, SF doesn’t automatically refresh the OData metadata for all entities. You need to manually trigger a metadata refresh in the Admin Center under System Configuration. Go to OData API Configuration and click ‘Refresh Metadata Cache’ for the Onboarding entity. This forces the system to rebuild the API schema including your new custom fields. Without this, the API layer doesn’t know about fields added through BTP extensibility.

3

That’s the classic H2 2023 custom field behavior! The $select parameter with custom fields requires the exact internal field name from the metadata, including any prefixes. But there’s also a known limitation - if you mix standard and custom fields in $select, you need to include the navigation property path. Try your query without $select first to confirm the exact field names in the response, then use those exact names in your $select. Also, some BTP custom fields require the entity navigation path like ‘cust_OnboardingExtension/custom_division’.

4

Check your BTP extensibility wizard configuration carefully. There’s a specific toggle for ‘Include in OData $select’ that’s separate from the general ‘API Enabled’ flag. If that’s not checked, fields appear in responses when you query all fields, but get filtered out when explicitly requested via $select. This is a security feature to prevent accidental exposure of sensitive custom fields.

5

Perfect timing to document the complete solution for BTP custom fields and OData API integration. This is a multi-step configuration issue that catches many developers.

BTP Extensibility Wizard Configuration: When creating custom fields through the BTP extensibility wizard, there are THREE API-related settings that must all be enabled:

  1. API Enabled: Basic flag that makes the field available through API (checked by default)
  2. Include in OData $select: Advanced setting that allows explicit field selection via $select parameter (NOT checked by default)
  3. Include in Metadata: Ensures field appears in $metadata endpoint (usually auto-enabled with API Enabled)

The ‘Include in OData $select’ toggle is under Advanced Settings in the wizard and is the most commonly missed configuration. Without it, fields appear when querying all fields (*) but disappear when explicitly requested.

API Metadata Cache Refresh: After deploying BTP extensions, the OData metadata cache must be manually refreshed:

  • Navigate to Admin Center > System Configuration > OData API Configuration
  • Find the OnboardingCandidateInfo entity
  • Click ‘Refresh Metadata Cache’
  • Wait 5-10 minutes for propagation across all API nodes

This step is MANDATORY - the API layer caches entity schemas and won’t recognize new fields until explicitly refreshed.

OData $select Usage with Custom Fields: Custom fields added via BTP use a namespace prefix. Check the $metadata endpoint to get exact field names:


GET /odata/v2/$metadata

Look for your entity and note the custom field names. They typically use format:

  • Standard BTP custom: `cust_fieldname
  • Extension-specific: `cust_ExtensionName/fieldname Correct query syntax:

GET /odata/v2/OnboardingCandidateInfo?$select=firstName,lastName,cust_custom_division,cust_custom_costcenter

Or with navigation for complex extensions:


GET /odata/v2/OnboardingCandidateInfo?$select=firstName,cust_OnboardingExtension/custom_division

H2 2023 Specific Behavior: In H2 2023, SF changed how $select handles custom fields for security reasons. If ‘Include in OData $select’ is disabled:

  • Query without $select: Custom fields INCLUDED in response
  • Query with $select=*: Custom fields INCLUDED
  • Query with explicit $select: Custom fields EXCLUDED (even if listed)

This prevents accidental exposure of sensitive custom data through poorly constructed API queries.

Verification Steps:

  1. Confirm all three wizard toggles enabled
  2. Refresh metadata cache and wait 10 minutes
  3. Query $metadata endpoint to verify field names
  4. Test query without $select to confirm fields appear
  5. Use exact field names from metadata in $select query

After following these steps, your custom fields should be fully accessible via OData API with proper $select support.

6

Found the toggle! It was under Advanced Settings in the BTP wizard. After enabling ‘Include in OData $select’ and refreshing metadata again, the $select queries now work correctly.