Skip to main content

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

  1. Autenticáte con una API key de una organización en sandbox.
  2. Llamá a POST /transactions con:
    • externalId que empiece con SIMULATE-ERROR-, o
    • metadata.sandboxErrorCode (canónico) o metadata.error_code (alias).
  3. 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

  1. metadata.sandboxErrorCode (si está y es reconocido)
  2. metadata.error_code (si está y es reconocido)
  3. 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.

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)

Elegir el error con metadata

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