## Comience por código, operación y entorno

Las respuestas de error documentadas usan un objeto `detail` con `code` y `message`. Compruebe también el estado HTTP. No trate un JSON de error como una transacción creada correctamente.

| Código | Comprobación recomendada |
| --- | --- |
| `validation_error` | Campos obligatorios, tipos, país, locale y límites |
| `invalid_api_key` | Credencial, revocación y entorno |
| `tenant_environment_disabled` | Habilitación del Tenant y entorno |
| `transaction_not_found` | Identificador, Tenant y entorno correctos |
| `idempotency_conflict` | Misma clave utilizada con payload diferente |
| `tenant_ip_not_authorized` | IP de salida autorizada para la operación |
| `api_key_scope_not_allowed` | Permisos de la clave para el recurso |

## Distinga conexión fallida de rechazo del contrato

Perder la respuesta de creación deja un resultado incierto. Utilice la misma clave de idempotencia y el mismo payload según la [guía de idempotencia](/es/desarrolladores/kyc/idempotencia). Los errores determinísticos de credenciales, alcance o payload requieren corrección; repetir sin límite solo oculta la causa.

Para indisponibilidad temporal, configure timeouts y reintentos limitados en su cliente. No suponga una promesa de disponibilidad ni un límite universal de intentos.

## Comparta un diagnóstico útil

Registre hora, entorno, método, ruta sin secretos, estado HTTP y código sanitizado. Cuando exista, vincule el identificador de transacción a la consulta de soporte. Retire claves, secretos de webhook, datos personales y enlaces de recorrido. Compare su llamada con la [referencia](/es/desarrolladores/kyc/referencia) y los [ejemplos](/es/desarrolladores/kyc/ejemplos-y-descargas) antes de modificar el proceso de negocio.