Seguridad y configuración

Los principios básicos para proteger claves de API son no exponerlas, aplicar el mínimo privilegio, rotarlas regularmente y mantener la trazabilidad del uso.

¿Cómo debo gestionar y proteger las claves de API?

Prácticas recomendadas:

• No incluyas claves de API en repositorios públicos, páginas frontend, paquetes móviles ni capturas de pantalla.
• Lee las claves desde variables de entorno o un gestor de secretos en el servidor.
• Crea claves distintas para desarrollo, pruebas y producción.
• Crea claves separadas por servicio o aplicación para mejorar trazabilidad y aislamiento.
• Configura permisos de modelos según las necesidades y establece fechas de caducidad cuando corresponda.
• Rota las claves regularmente; hazlo de inmediato tras cambios de personal, cierre de servicios o sospechas de filtración.

Si una clave puede haberse filtrado:

1. Desactiva, elimina o rota la clave antigua inmediatamente.
2. Crea una clave nueva y actualiza todos los servicios dependientes.
3. Revisa uso reciente, cambios de saldo y gastos anómalos.
4. Restringe los permisos de modelos y considera una caducidad más corta.
5. Revisa la vía de filtración, como repositorios, registros, configuración de CI o clientes de terceros.

Una filtración puede causar llamadas no autorizadas y pérdidas económicas. Incluso las claves de prueba deben protegerse como secretos de producción.

¿Puedo volver a ver la clave de API completa después de crearla?

No. La clave completa solo se muestra durante el proceso de creación correcto. Después, la consola únicamente muestra una vista enmascarada.

Antes de cerrar el diálogo de creación, guarda la clave en una variable de entorno del servidor o un gestor de secretos. Una clave perdida no puede recuperarse mediante las API de usuario ni de administrador. Crea una sustituta, actualiza el cliente y después elimina la antigua. La plantilla de integración de IA de la documentación usa un marcador <API_KEY> y no carga claves históricas.

¿Cómo debo enviar una clave de API?

Envía las claves únicamente en las cabeceras de la solicitud. Recomendamos:

Authorization: Bearer YOUR_API_KEY

También puedes usar:

X-API-Key: YOUR_API_KEY

Nunca incluyas credenciales de API de RequestBeam en los parámetros de la URL. Los nombres propios de credenciales (apiKey, api_key, apikey, x-api-key y key) normalmente provocan HTTP 400. Las excepciones limitadas de parámetros de negocio de Similarweb se aplican solo a solicitudes GET: /v1/similarweb/websites/backlinks admite un único nombre de host en Key, con mayúscula; /v1/similarweb/websites/outgoing-traffic, /websites/incoming-referrals y /websites/similar-sites/suggestions admiten un único nombre de host en key, con minúscula (todos bajo /v1/similarweb). Estos campos identifican un sitio objetivo, no una credencial de API. Los nombres de host deben ser válidos. Los duplicados, mayúsculas incorrectas, valores similares a credenciales y parámetros de credenciales adicionales siguen bloqueados. Autentícate siempre mediante una cabecera, también en rutas de Similarweb. Consulta el ejemplo de solicitud de Similarweb.

Esta regla no afecta a otros parámetros de negocio, como token de OAuth, apiKeyId, username o pagination_token.