La clave de API de un servicio de RUC es una credencial, no un dato de configuración visible. El contrato de OwnData lo dice de forma explícita: la clave es de uso exclusivo del servidor y no debe incluirse en código de navegador ni de aplicaciones móviles. Por eso el patrón correcto es que el navegador llame a tu propio endpoint y que ese endpoint llame al proveedor.

La solicitud al proveedor es simple: un GET a https://app.controlaria.online/api/v1/ruc/ seguido del RUC, con el encabezado X-API-Key. Tu servidor lee la clave desde una variable de entorno, arma la URL con el RUC ya validado y, opcionalmente, fija un tiempo máximo de espera. La dirección del proveedor debe estar fija en tu código; nunca la construyas con datos que llegan del navegador.

En Next.js, la documentación oficial indica que las variables de entorno solo están disponibles en el servidor, salvo las que empiezan con NEXT_PUBLIC_, que se exponen al cliente. Entonces la clave no debe llevar ese prefijo. Tampoco conviene leerla en cualquier archivo: la guía de seguridad de Next.js recomienda concentrar el acceso a los secretos en una capa de acceso a datos que corre solo en el servidor, y marcar esos módulos con el paquete server-only para que el build falle si alguien los importa desde un componente de cliente.

Antes de llamar al proveedor, validá la entrada en tu servidor: solo dígitos y un guion opcional, y el dígito verificador si viene incluido. Con eso evitás gastar cupo en consultas que el proveedor va a rechazar. Devolvé al navegador solo los campos que la pantalla necesita, por ejemplo fullRuc, nameOfficial y la fecha de publicación, y no el objeto completo del proveedor.

Al responder, traducí los códigos de error del proveedor a mensajes útiles para tu usuario. No encontrado permite seguir con carga manual; cupo agotado puede mostrar la hora de reinicio a partir del encabezado Retry-After; no disponible invita a reintentar más tarde. No registres claves ni RUC completos con nombre en los logs, y no reintentes automáticamente respuestas 400, 401 o 404: no van a cambiar.

Por último, protegé tu propio endpoint: exigí sesión o algún control equivalente, y aplicá un límite de velocidad por usuario. Si no, cualquiera podría usar tu servidor como intermediario para agotar tu cupo diario.