AIREITEREl mensaje The request is prohibited due to a violation of provider Terms Of Service no suele indicar que te hayas quedado sin créditos en OpenRouter. Señala, más bien, que la solicitud ha llegado a una decisión de política o control de acceso. Lo complicado es que ese mismo error con forma de 403 puede deberse a un prompt bloqueado, una restricción de cuenta o región, o el rechazo de un proveedor upstream. Antes de cambiar claves o rehacer toda la integración, averigua en qué capa se produjo el rechazo.
Qué significa realmente este error de OpenRouter
Los Terms of Service de OpenRouter, actualizados por última vez el 31 de agosto de 2026, establecen que cada modelo está sujeto a los términos aplicables de su proveedor, que el proveedor conserva el control sobre el acceso al modelo y que OpenRouter puede limitar el acceso si considera razonablemente que dichos términos se han incumplido o podrían incumplirse. Por tanto, el error puede responder a una decisión del proveedor upstream, a una medida aplicada por OpenRouter o a ambas cosas; el texto por sí solo no permite saber cuál.
Tampoco equivale a cualquier otro fallo de la API:
| Respuesta | Suele indicar | Primero revisa |
|---|---|---|
| 401 | Autenticación | Clave de API, cabecera, estado de la clave |
| 402 | Créditos o límite de gasto | Saldo de la cuenta, límite de la clave, uso |
| 403 de términos del proveedor | Política, permiso, región, barrera de seguridad o acceso del proveedor | Error JSON completo y metadatos del proveedor |
| 429 | Límite de velocidad | Retry-After, frecuencia de solicitudes |
Un 403 no demuestra que el último prompt fuera ilegal, ni que toda tu cuenta de OpenRouter esté bloqueada de forma permanente.
Identifica primero dónde se rechaza la solicitud
La pregunta útil no es «¿cómo esquivo el error?», sino «¿en qué punto de decisión se rechazó esta solicitud?». Antes de probar nada más, guarda el slug del modelo, el proveedor seleccionado, el cuerpo completo de la respuesta, la marca de tiempo y el ID de solicitud.
Indicadores de un rechazo en el proveedor upstream
Un nombre de proveedor, un mensaje author banned, texto de moderación específico de un proveedor o un fallo limitado a un único modelo o proveedor apuntan a una decisión de acceso upstream. Los términos de OpenRouter indican que cada Model Provider conserva el control exclusivo del acceso a su modelo y que, si se suspende el acceso, puede ser necesario contactar con el proveedor correspondiente.
Una incidencia pública de GitHub ilustra por qué importan los campos sin procesar: un flujo de revisión de PDF de Coarse recibió HTTP 403 mediante LiteLLM, pero el campo provider_name tenía el valor null. El informe mostraba un saldo de $20 en OpenRouter, así que la evidencia no respaldaba un diagnóstico de «créditos insuficientes».
Indicadores de controles de cuenta, espacio de trabajo o enrutamiento
Si una solicitud neutral falla con varios proveedores no relacionados, sospecha primero de una condición de cuenta, espacio de trabajo, región, credenciales o enrutamiento, en lugar de culpar a un único prompt. Los términos de OpenRouter le permiten suspender o limitar las credenciales de API cuando considere razonablemente que es necesario para proteger el servicio o a un tercero. También prohíben usar VPN o proxies para acceder a modelos restringidos.
El directorio de proveedores de OpenRouter muestra diferencias a nivel de proveedor, como retención, entrenamiento, disponibilidad de BYOK, sede y enlaces a los términos de cada proveedor. Estos campos ayudan a seleccionar una ruta apta, pero no prueban que una cuenta concreta haya sido bloqueada por un motivo específico.
Un diagnóstico seguro en 10 minutos
En vez de reenviar una y otra vez la solicitud rechazada, utiliza una pequeña matriz de pruebas.
- Conserva la evidencia original. Copia la respuesta JSON completa, el estado HTTP, el ID de solicitud, el slug del modelo, la ruta del proveedor, la marca de tiempo y la versión del cliente o SDK. Antes de compartirlos, elimina la clave y el contenido privado del prompt.
- Envía una solicitud mínima y neutral. Haz una pregunta factual breve, sin archivos, herramientas, juegos de rol, lenguaje de red team ni un prompt de sistema complejo. No sigas reintentando la carga útil original.
- Fija un modelo y un proveedor. Desactiva temporalmente los fallbacks automáticos para que una respuesta correcta revele qué ruta funcionó.
- Revisa el registro de Activity. Busca el intento del proveedor, la respuesta sin procesar del proveedor y cualquier metadato
provider_responseso relacionado que exponga el panel o la integración. - Repite la prueba con un segundo proveedor apto. Mantén el prompt neutral y una capacidad de modelo lo más parecida posible. El fallo de un proveedor no es lo mismo que un fallo entre varios proveedores.
- Compara el alcance de la cuenta. Comprueba si el problema afecta a un modelo, una familia de proveedores, un espacio de trabajo o todos los modelos disponibles para la cuenta. No crees cuentas para eludir una restricción.
- Revisa las barreras de configuración. Comprueba las guardrails del espacio de trabajo, el orden de proveedores, los requisitos de retención de datos o zero-data-retention, los ajustes de región de datos, los permisos de la clave de API y las listas de IP permitidas.
- Detente si hay coincidencia con una política. Si la solicitud original entra claramente en conflicto con los términos del modelo, modifica el caso de uso en vez de dirigirlo a más proveedores.
El resultado será mucho más útil que una suposición:
| Resultado de la prueba | Diagnóstico probable | Siguiente paso |
|---|---|---|
| Solo un proveedor rechaza; otro acepta la prueba neutral | Restricción específica del proveedor o endpoint | Usa un proveedor apto para una carga de trabajo compatible o contacta con el proveedor |
| Varios proveedores rechazan pruebas normales bajo una misma cuenta | Señal de aplicación compartida de cuenta, espacio de trabajo, región o credenciales | Revisa los ajustes y contacta con OpenRouter aportando evidencia |
| Solo falla el prompt o archivo adjunto original | Política sobre el contenido de la solicitud, el contexto, el archivo o la herramienta | Elimina o modifica el material que activa el rechazo |
| Todas las solicitudes devuelven en su lugar 401, 402 o 429 | Otra clase de fallo | Sigue el proceso de autenticación, facturación o límite de velocidad |
Qué puede activar el mensaje y qué sigue sin demostrarse
El mensaje sobre los términos del proveedor puede estar asociado a algo más que una única frase del prompt. Entre los posibles factores se incluyen:
- Contenido no permitido o una conversación extensa que contiene contexto no permitido.
- Instrucciones de sistema, llamadas a herramientas, carga de archivos, pruebas de prompt injection o actividad de red team no autorizada.
- Un modelo restringido por geografía, tipo de organización o reglas de elegibilidad del proveedor.
- Señales de cuenta, espacio de trabajo, pago, IP o región utilizadas por los controles de riesgo de un proveedor upstream.
- Una incompatibilidad entre tus requisitos de región de datos o retención y el endpoint disponible.
- Una clave de proveedor sin permiso para el modelo seleccionado al usar BYOK.
Los términos de OpenRouter confirman que los proveedores pueden restringir modelos en determinados países o regiones, y que OpenRouter puede solicitar información que respalde el cumplimiento. Sin embargo, no publican una lista universal con las señales exactas que generan este error. Los informes de la comunidad sirven para detectar patrones, pero no pueden demostrar que una tarjeta de pago, una VPN, un país o un prompt concretos hayan causado un bloqueo individual.
«Tu “proceso de bloqueo” es totalmente opaco. A día de hoy, no creo que nadie que haya sido bloqueado sepa con un 100 % de certeza por qué le prohibieron el acceso; solo pueden hacer conjeturas». — u/pip25hu, r/openrouter
Precisamente por esa incertidumbre, la respuesta sin procesar del proveedor y una comparación controlada valen más que las explicaciones anecdóticas.
Soluciones válidas frente a atajos que no lo son
Sigue el camino que corresponda al resultado de las pruebas:
- Problema de contenido o contexto: elimina el material marcado, acorta la conversación, quita instrucciones de sistema innecesarias y rediseña el flujo de trabajo conforme a las reglas de uso aceptable del proveedor.
- Restricción de modelo o proveedor: elige un modelo y un endpoint que puedas utilizar. Consulta los términos enlazados del proveedor desde el directorio de proveedores de OpenRouter.
- Conflicto de espacio de trabajo o política de datos: ajusta una guardrail, configuración de retención o región legítima solo si encaja con los requisitos de tu organización. Una política de ZDR o región más estricta puede excluir endpoints que, de otro modo, serían válidos.
- Problema de permisos de BYOK: verifica que la clave del proveedor esté habilitada para el modelo, la región y la cuenta. BYOK cambia la credencial utilizada; no elimina los términos del proveedor ni habilita un endpoint restringido.
- Restricción a nivel de cuenta: deja de reintentar repetidamente, reúne la evidencia y contacta con el soporte de OpenRouter. Pregunta qué modelo o proveedor está restringido y qué información de cumplimiento se requiere.
Cambiar de proveedor puede ser una medida válida de continuidad si la nueva ruta está permitida para el mismo caso de uso. No autoriza a enviar contenido prohibido a otro sitio. No uses VPN, proxies, cuentas nuevas ni la creación repetida de claves para eludir un control de modelos restringidos; los términos de OpenRouter prohíben expresamente sortear esas salvaguardas.
Cómo contactar con soporte sin perder la evidencia útil
Incluye un paquete de diagnóstico conciso:
- Identificador de cuenta o espacio de trabajo, pero nunca la clave de API.
- Slug exacto del modelo y ruta de proveedor prevista.
- Marca de tiempo UTC e ID de solicitud.
- Estado HTTP y JSON completo del error, ya saneado.
- Si una solicitud neutral funcionó y con qué proveedor.
- Si el fallo afecta a un modelo, a varios proveedores o a todo el espacio de trabajo.
- Ajustes relevantes de guardrails, región, ZDR, BYOK o lista de IP permitidas.
- Una descripción breve del caso de uso, sin pegar prompts sensibles salvo que soporte los solicite expresamente.
Pregunta si el rechazo procede del proveedor, de los controles de cuenta de OpenRouter o de una regla de enrutamiento o política de datos. Si la respuesta identifica a un proveedor upstream, los términos de OpenRouter indican que debes contactar con ese proveedor para resolver el acceso al modelo. No des por hecho que una nueva clave de API eliminará una restricción a nivel de cuenta.
Preguntas frecuentes sobre el error de términos del proveedor en OpenRouter
¿Es un bloqueo de OpenRouter?
No necesariamente. Puede ser un rechazo de un único proveedor o modelo, una restricción de cuenta o espacio de trabajo, una decisión de guardrail o una respuesta de un proveedor upstream. El texto del error por sí solo no permite confirmar un bloqueo permanente.
¿Me está rechazando el proveedor o OpenRouter?
Revisa el nombre del proveedor, los metadatos sin procesar, el registro de Activity y si proveedores no relacionados fallan con la misma prueba neutral. Los términos de OpenRouter confirman que los proveedores mantienen el control sobre el acceso a los modelos, mientras que OpenRouter también puede restringir el acceso al servicio y a las credenciales.
¿Un prompt inocuo puede producir este error?
Sí. Una prueba inocua puede fallar cuando la restricción está vinculada a una cuenta, región, credencial, espacio de trabajo o condición de elegibilidad del proveedor, y no a la frase actual. Eso sirve para diagnosticar, no para demostrar qué señal causó la restricción.
¿Una nueva clave de API o una VPN lo solucionarán?
No hay un motivo fiable para esperar que ninguna de las dos resuelva una restricción de cuenta o proveedor. El uso de VPN o proxy puede incumplir por sí mismo las reglas de OpenRouter sobre modelos restringidos. Comprueba tu elegibilidad y contacta con soporte en vez de intentar eludir la aplicación de las normas.
¿Pueden cobrarme por un 403?
No deduzcas la facturación solo a partir del código de estado. Revisa el uso y el registro de Activity de la solicitud. Una solicitud rechazada debe conciliase con el registro real, en vez de dar por hecho que fue gratuita o que se cobró.
¿Debo usar BYOK u otro proveedor?
Usa BYOK cuando estés autorizado a utilizar ese proveedor y necesites controlar las credenciales, límites o costes del proveedor. Usa otro proveedor únicamente si permite la misma carga de trabajo. Ninguna de las dos opciones anula los términos del proveedor, las restricciones regionales ni las políticas de datos de tu organización.
La regla práctica es sencilla: si falla un proveedor apto, compara con otra ruta compatible; si varios proveedores fallan con una solicitud neutral, deja de reintentar e investiga las condiciones de cuenta, espacio de trabajo, región y credenciales; si solo falla el contenido original, modifica la solicitud en vez de buscar una ruta alternativa para sortear la restricción.