Response Normalization
Reshaping outside API responses into one schema your app owns, so vendor field names and quirks stop spreading through the codebase.
See it
What it is
Response normalization converts outside data into a stable schema your application owns. One provider's `first_name`, another's `properties.firstname`, and a third's nested profile can all become the same `firstName` field at the integration boundary.
Reach for it when you support multiple providers or when a vendor's response shape should not leak through the whole codebase. A small adapter per provider gives the rest of the app one model to validate, test, and evolve. It also gives vendor-specific errors one consistent internal form.
Normalization can hide information if the target schema is too neat. Decide explicitly how missing, null, empty, and unknown values differ, and preserve the provider ID for debugging. Validate before mapping and fail visibly on a new enum value; silently turning unfamiliar data into a default creates bugs that look valid.
Ask AI for it
Create response adapters that normalize Stripe Customer objects and HubSpot contacts into one Zod-validated Customer schema with id, email, firstName, lastName, provider, and providerId. Map Stripe id, email, name, and metadata separately from HubSpot properties.email, properties.firstname, and properties.lastname. Distinguish missing, null, and empty strings, reject unknown provider enum values, preserve the raw provider ID in errors, and add fixture tests for both sources.