# API · Cómo leer una respuesta de error

> Un HTTP 200 no significa éxito. Dónde viene el rechazo del emisor y cómo escribir el manejo de errores.

- kind: api-operation
- status: stable
- api_version: v1
- last_verified: 2026-08-28
- url: https://www.tilopay.com/developers/api/procesos-operativos/errors

## El rechazo del emisor [#rechazo]

Cuando el emisor rechaza una transacción, la respuesta trae dos campos:

<Param id="error-code" name="code" type="string">
El código de rechazo del emisor.
</Param>

<Param id="error-description" name="description" type="string">
El texto del rechazo.
</Param>

## Un HTTP 200 no significa éxito [#estado-http]

<Callout type="warn">
**No hay un estándar definido de cuándo el API responde HTTP 4xx y cuándo responde HTTP 200 con
el error en el cuerpo.** Conviven las dos formas, y hay **cuatro envolturas distintas de error
según el endpoint**.

Consecuencia práctica: tu manejo de errores tiene que mirar el cuerpo siempre, no solo el
código de estado, y tolerar más de una forma de cuerpo.
</Callout>

## Cómo escribir el manejo de errores [#como-manejar]

- Tratá `code` y `description` como datos para registrar y mostrar, no como una enumeración
  sobre la que ramificar.
- No hagas `if (status === 200) éxito`. Verificá el cuerpo.
- Guardá la respuesta cruda de cada rechazo: es lo que te permite reconstruir el patrón de
  rechazos de tu comercio.
- Para decidir el estado real de una transacción después de un fallo, usá
  [reintentos seguros](/developers/concepts/reintentos-seguros).