Resumen
Solo en sandbox, POST /transactions puede devolver una respuesta de error predefinida sin crear la transacción. Sirve para probar cómo se comporta tu sistema cuando el monitoreo no está disponible, hace timeout o rechaza el pedido.
Estos disparadores se ignoran en producción. Una organización de producción siempre sigue el flujo normal de create, aunque envíes un externalId o código de metadata de simulación.
Cómo funciona
- Autenticáte con una API key de una organización en sandbox.
- Llamá a
POST /transactions con:
externalId que empiece con SIMULATE-ERROR-, o
metadata.sandboxErrorCode (canónico) o metadata.error_code (alias).
- Gu1 responde con el HTTP status y el body correspondientes de inmediato (o tras un delay acotado en timeout). No se escribe ninguna fila en
transactions.
Prioridad al elegir el código
metadata.sandboxErrorCode (si está y es reconocido)
metadata.error_code (si está y es reconocido)
- Sufijo después de
SIMULATE-ERROR- en externalId (por ejemplo SIMULATE-ERROR-TIMEOUT)
Un código desconocido devuelve 400 con error.code UNKNOWN_SANDBOX_ERROR_CODE y el listado de códigos válidos.
Catálogo
Alias útiles
Podés usar alias cortos en el sufijo o en metadata: TIMEOUT, UNAVAILABLE, 500, 504, 429, 409, 403, VALIDATION, DUPLICATE, QUOTA, INTERNAL_ERROR, FAILED_TO_CREATE.
Ejemplos
Timeout (indisponibilidad / sin respuesta a tiempo)
Alias (mismo efecto en sandbox):
Ejemplo de body 504
Alcance
- Solo aplica a
POST /transactions individual. Los endpoints de batch no están cubiertos.
- Fallos de auth / permisos (401 / 403 del middleware) no se simulan acá — usá una key o rol inválido si los necesitás.
- Los creates exitosos (201) no cambian; esta feature solo simula errores.
Relacionado