Conectividad

Antes de que cualquier solicitud llegue a la API de Remesas, se deben cumplir dos requisitos a nivel de borde (edge). Estos se aplican en el perímetro de la red (CDN + WAF), no dentro de la API — por lo que una configuración incorrecta se manifiesta como una falla en el handshake TLS o un 403 Forbidden sin cuerpo, no como uno de los errores JSON documentados en otras secciones.

1. TLS Mutuo (mTLS)

Cada solicitud debe presentar un certificado de cliente emitido por Inyo. Las solicitudes sin un certificado de cliente válido se rechazan durante el handshake TLS, antes incluso de que se negocie HTTP.

Durante el aprovisionamiento del tenant, recibes dos archivos de Inyo:

Archivo	Propósito
`client.crt`	Tu certificado público de cliente
`client.key`	La clave privada correspondiente — manténla en secreto; trátala como una contraseña

Configura tu cliente HTTP para presentar el certificado en cada solicitud. Almacena la clave en un gestor de secretos, no en tu repositorio.

2. Dirección IP Fija

Tu IP de salida debe estar en la lista de permitidos (allowlist) de Inyo. Las solicitudes desde IPs no listadas se descartan en el WAF y devuelven 403 Forbidden sin cuerpo JSON.

Coordina con Inyo antes de:

Rotar gateways NAT de salida
Agregar nuevas regiones o zonas de disponibilidad
Migrar a un nuevo proveedor de hosting

Actualizar la lista de permitidos es una solicitud de soporte rápida sin cambios de código — pero una lista desactualizada se manifiesta como una interrupción total desde tu lado.

Ejemplo Funcional con curl

Una vez que tienes los archivos de certificado y tu IP está en la lista de permitidos:

curl -sS \
  --cert /path/to/client.crt \
  --key  /path/to/client.key \
  --header "x-api-key: $API_KEY" \
  --header "x-agent-id: $AGENT_ID" \
  --header "x-agent-api-key: $AGENT_KEY" \
  --header "Content-Type: application/json" \
  https://{FQDN}/organizations/$TENANT/people \
  --data '{ ... }'

Modos de Falla Comunes

Síntoma	Causa probable
`curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL` / handshake abortado	Certificado de cliente faltante, incorrecto o vencido (`--cert`, `--key`)
`403 Forbidden` con cuerpo vacío o HTML	IP de salida no está en la lista de permitidos
`401 Unauthorized` + `{"error":"UNAUTHORIZED", ...}`	Las verificaciones de mTLS e IP pasaron, pero los headers de API key faltan o son incorrectos — ver Autenticación
`403 Forbidden` + `{"error":"FORBIDDEN", ...}`	Credenciales válidas, pero el `{tenant}` en la URL no coincide con el tenant propietario de la API key, o el agente no está aprobado

Regla general: si estás recibiendo un cuerpo de error JSON, ya superaste las verificaciones de mTLS e IP — el problema está en la capa de aplicación (credenciales, payload o reglas de negocio).