API · Convenciones de las respuestas

Las respuestas del API de adquirencia tienen tres detalles que no se deducen leyendo cada operación por separado y que rompen integraciones tipadas. Están acá porque aplican a varias operaciones a la vez.

Para el manejo de errores, ver cómo leer una respuesta de error.

Los montos vienen como cadena, no como número#

Cualquier deserialización tipada que declare esos campos como número falla. Declaralos como cadena y convertilos vos, con el tipo decimal de tu lenguaje, no con punto flotante.

Aparece, entre otras, en obtener un cupón, listar cupones, listar planes y pagos de suscriptor.

Hay un JSON dentro de una cadena#

En pagos de suscriptor, el campo data de cada pago no es un objeto: es una cadena que contiene JSON.

"data": "{\"first\":1,\"expire\":\"2024-12-28T19:05:29.572648Z\",\"amount\":0,\"activeAmount\":0,\"originalAmount\":0,\"key\":\"XXXX-XXXX-XXXX-XXXX-XXXX\"}"

Hay que deserializar dos veces: primero la respuesta, después el contenido de data. Tratá esa segunda deserialización como puede fallar cualquier entrada externa: envolvela y registrá la cadena cruda si no parsea.

La misma entidad cambia de forma entre "obtener uno" y "listar"#

No es un descuido de la documentación: las dos operaciones devuelven formas distintas del mismo cupón, y hay que mapearlas por separado.

Lo mismo pasa en pagos de suscriptor, que también usa create con formato Y-m-d H:i:s.

Dos formas de decir "no configurado"#

En listar planes, los campos de webhook de un plan vienen como cadena vacía cuando no están configurados, mientras que return_url viene como null. Son dos representaciones del mismo estado en el mismo objeto: al verificar si un webhook está configurado, tratá la cadena vacía y null como el mismo caso.