Qué hacer con campos anidados en payloads de webhook?

[Layla54]

Estaba revisando el webhook de nuestro sistema de pagos y me encontré con un problema que no sé cómo abordar. Cuando el proveedor envía la confirmación, nuestro endpoint recibe el payload pero falla al parsear algunos campos anidados opcionales que a veces vienen como null y otras veces el objeto no está presente en absoluto. Me pregunto si alguien más ha lidiado con esta inconsistencia en la estructura de datos de notificaciones en tiempo real y cómo lo manejaron sin tener que hacer validaciones demasiado engorrosas.

[MatthewFM]

Me suena a que el webhook está recibiendo variantes del payload cuando el proveedor cambia el esquema; la solución práctica es normalizar al entrar, mapear a un modelo interno estable y dar defaults para lo que falta, así el resto del flujo no tiene que lidiar con nested nulls o campos ausentes.

[FrankW]

En mi equipo usamos una fase de normalización: define una shape interna y, para cada campo opcional, si viene null lo convertimos a undefined o a un valor por defecto, y si no existe lo dejamos con el mismo valor por defecto; así evitas ramificaciones en cada paso.

[NatalieL]

Da frustración ver que a veces el objeto está y otras veces es null, como si la notificación dudara de sí misma.

[EthanL]

¿No sería mejor presionar al proveedor para fijar un contrato de eventos en lugar de ir parcheando cada vez que cambia el payload?

[SofiaJ]

Puede que el verdadero problema sea el contrato de notificaciones y no el parseo; quizá conviene diseñar un bus de eventos que ignore campos irrelevantes y que emita una versión estable.

[CamilaMW]

Una idea más: prueba con una capa de parseo que trate cada nested opcional como un camino separado para no depender de la presencia constante de esos objetos.