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?
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.
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.
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.
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.
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.