Custom JavaScript data mapping fails on external API response

We’re experiencing issues with custom JavaScript mapping in Integration Hub when processing external API responses. Our integration pulls customer data from a third-party system, but the JS mapping function fails when handling nested JSON structures. The API response contains nested objects with customer addresses and contact details, and our mapping script can’t properly extract values from deeply nested properties. We’ve tried accessing properties using dot notation but keep getting undefined values. The error appears inconsistently - sometimes it works for simple responses but fails when the nesting goes beyond two levels. Here’s what we’re attempting:

const address = response.data.customer.addresses[0].street;
const phone = response.data.customer.contacts.primary.phone;

This results in incomplete CRM records with missing address and contact information. Has anyone dealt with nested JSON parsing in Integration Hub’s client-side mapping layer?

The core issue here involves three interconnected aspects that need proper handling in your Integration Hub mapping layer.

First, nested JSON parsing requires defensive programming when dealing with external APIs. The problem with your original code is the assumption that every property in the chain exists. External APIs rarely guarantee complete data structures, especially for optional fields like secondary addresses or alternate contacts. You need to validate each level of nesting before attempting to access deeper properties. For aec-2021’s JavaScript runtime, implement explicit checks rather than relying on newer ES6+ features.

Second, client-side JS mapping in Integration Hub has specific constraints around error handling. When a mapping function throws an error due to undefined property access, the entire record processing can fail silently or partially complete, leading to your incomplete CRM sync issue. The solution is to wrap your mapping logic in try-catch blocks and provide default values for missing data:

function safeMap(response) {
  const customer = response.data?.customer || {};
  const addresses = Array.isArray(customer.addresses) ? customer.addresses : [];
  const primaryAddress = addresses[0] || {};

  return {
    street: primaryAddress.street || 'N/A',
    phone: customer.contacts?.primary?.phone || null
  };
}

Third, API response structure validation should happen before mapping. Add a schema validation step that checks for required properties and logs warnings for unexpected structures. This helps identify when the external API changes its response format. Create a mapping configuration that defines fallback values for each field, ensuring your CRM records are always complete even when source data is partial.

Implement these three layers - defensive parsing, error-safe mapping, and structure validation - and your integration will handle variable API responses reliably. Also consider implementing a data quality report that tracks how often fallback values are used, giving you visibility into API data completeness over time.


This draft is based on general Adobe Experience Cloud knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

I’ve seen similar behavior with deeply nested API responses. The issue often stems from how Integration Hub handles optional properties in the response chain. If any intermediate property is null or undefined, the entire chain breaks. You need defensive checking at each level before accessing nested values.

Check your API response structure first - use console logging to verify the actual shape of the data. Integration Hub’s JavaScript runtime can be strict about property access. I’d recommend using optional chaining or explicit null checks. Also, are you handling array access safely? The [0] index might not always exist if the addresses array is empty in some responses.

This is a common pattern issue. Your mapping script needs to account for variable response structures from external APIs. Consider implementing a helper function that safely traverses nested objects. Something like a getNestedValue utility that returns null for missing paths instead of throwing errors. Also verify that your Integration Hub version supports ES6 features like optional chaining - aec-2021 might have limitations there.

Have you looked at the actual API response format in the Integration Hub logs? Sometimes the structure differs from documentation. I’d suggest adding comprehensive error handling around each nested access point. You might also want to check if the API is returning consistent data types - occasionally external systems return strings where you expect objects, which breaks dot notation access completely.

Thanks for the suggestions. I’ve been logging the responses and confirmed the structure varies - some customer records have missing address arrays or null contact objects. The inconsistency is definitely the root cause here.

Tested this on Adobe Experience Platform’s Integration Hub with nested Salesforce API responses, and defensive null checks at each JSON level eliminated all mapping failures immediately.

Good catch on the structure variance. For aec-2021, you’ll need explicit null checking since optional chaining isn’t fully supported. Here’s a more defensive approach:

const addresses = response?.data?.customer?.addresses || [];
const address = addresses.length > 0 ? addresses[0].street : null;
const contacts = response?.data?.customer?.contacts || {};
const phone = contacts.primary ? contacts.primary.phone : null;

This handles missing properties gracefully without breaking the mapping chain.