Dale a tus flujos de Activepieces un proveedor de IA compatible con OpenAI.

Respuesta rápida: una entrada de proveedor en la configuración de IA de administración.

En la consola de administración de Activepieces, abre la página de configuración de IA y añade un proveedor de tipo OpenAI Compatible. El formulario pide un Display Name, una API Key, una Base URL, un API Key Header, headers por defecto opcionales, y una lista de modelos donde cada entrada tiene un Model ID, un Model Name y un Model Type. Los valores para APIsRouter: Base URL es https://api.apisrouter.com/v1 (la misma forma que usa el propio código para sus proveedores compatibles integrados), API Key Header es Authorization, y el campo de clave recibe tu clave de gateway. Un detalle de implementación que conviene conocer: Activepieces envía la clave en ese header exactamente como la escribiste, sin añadir automáticamente el prefijo Bearer, así que introdúcela como "Bearer sk-..." para la forma canónica; APIsRouter también acepta la clave sin prefijo en el header Authorization, así que ambas formas funcionan aquí. Luego añade cada modelo que quieras que vean los flujos, con el Model ID coincidiendo exactamente con el catálogo.

Admin Console -> AI setup -> Add AI Provider
  -> OpenAI Compatible

Display Name:   APIsRouter
Base URL:       https://api.apisrouter.com/v1
API Key Header: Authorization
API Key:        Bearer sk-YOUR-APISROUTER-KEY

Models (Add Model):
  Model ID: claude-haiku-4-5-20251001  Type: TEXT
  Model ID: deepseek-v4-flash          Type: TEXT
  Model ID: claude-sonnet-4-6          Type: TEXT

Cómo usa Activepieces un proveedor personalizado.

Activepieces (unas 23K estrellas en GitHub) es la plataforma de automatización no-code de código abierto líder: flujos construidos a partir de triggers y piezas, con la forma de Zapier pero autoalojable, con un framework de piezas licenciado en MIT y un gran catálogo de la comunidad. Sus capacidades de IA (pasos de generación de texto, agentes, piezas de utilidad de IA) resuelven su modelo a través de los proveedores de IA configurados en la plataforma, que es lo que convierte la entrada de proveedor en una decisión de enrutamiento para todos los flujos a la vez. Por debajo, el proveedor OpenAI Compatible construye un cliente estándar contra tu Base URL y adjunta tu clave bajo el nombre de header que elegiste, además de headers de metadatos por ejecución que identifican el proyecto y el flujo. El Model ID que registraste se pasa tal cual como el string del modelo en las peticiones de chat-completions. No hay auto-descubrimiento de modelos para este tipo de proveedor: los flujos solo pueden seleccionar exactamente los modelos que añadiste a la lista, lo que mantiene el selector intencional en lugar de saturado. La configuración del proveedor es a nivel de plataforma. Un administrador la define una vez, y cada proyecto y flujo en la instancia selecciona entre los modelos registrados. Esa centralización es la ganancia de gobernanza: un solo lugar para decidir qué modelos existen, una sola clave para medir todos los pasos de IA, y los metadatos por flujo en cada petición hacen que el uso sea atribuible cuando revisas los logs.

Configuración completa y la advertencia al guardar.

El formulario se guarda sin validar la conexión; la implementación del proveedor omite explícitamente las comprobaciones de conexión para el tipo OpenAI Compatible. Eso es cómodo (no se sondea tu endpoint al guardar) pero significa que una Base URL incorrecta o una clave malformada falla más tarde, en la primera ejecución de flujo que toque un paso de IA. Verifica el endpoint a mano una vez antes de conectarlo a flujos de producción, y trata la primera ejecución como parte de la configuración. El Model Type importa para qué piezas pueden usar la entrada: los pasos de texto quieren modelos TEXT. Registra el id exactamente como lo escribe el catálogo; el Model Name es una etiqueta visual y puede ser cualquier texto legible. Si quieres el mismo modelo subyacente en dos niveles de precio-rendimiento para equipos distintos, regístralo una vez por Model ID; los nombres visuales los mantienen distinguibles en el selector.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001",
       "messages":[{"role":"user","content":"ping"}]}'

Elegir modelos para pasos de automatización.

Como el proveedor es a nivel de plataforma, la gobernanza de modelos es una sola pantalla: añade los ids que apruebas, observa una semana de uso por clave, y poda lo que nadie debería usar. Los creadores de flujos mantienen su libertad dentro de la lista que curaste.

• La IA de automatización es trabajo de alto volumen y prompt corto: clasificar un ticket, extraer campos, redactar un mensaje, resumir un payload de webhook. claude-haiku-4-5-20251001, gpt-5.4-mini y deepseek-v4-flash cubren la mayoría de los pasos a precios de volumen.
• Reserva un id más fuerte para los pasos de juicio. Un flujo que redacta respuestas de cara al cliente o toma decisiones de enrutamiento merece claude-sonnet-4-6, seleccionado por paso en el constructor de flujos.
• MiniMax-M2.7 y la familia DeepSeek tienen un precio extremadamente bueno para flujos de transformación masiva (feeds, limpiezas de scraping, enriquecimiento) donde miles de ejecuciones al día son normales.
• Los flujos se ejecutan sin supervisión, así que el coste es una programación multiplicada por un recuento de tokens por ejecución. El log de uso te da el número por ejecución; la programación es tuya.
• Registra pocos modelos de forma deliberada. El selector muestra exactamente lo que añadiste, y una lista curada evita que cien creadores de flujos elijan cada uno algo distinto.

Pago por uso · por debajo del precio oficial

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Modos de fallo específicos de Activepieces.

Guardado silencioso, primera ejecución ruidosa. Como el proveedor OpenAI Compatible omite la validación de conexión, cualquier error de conexión (Base URL incorrecta, /v1 faltante, clave incorrecta, nombre de header equivocado) aparece como un paso de IA fallido en una ejecución de flujo en lugar de un error de formulario. Cuando un paso de IA falla justo después de cambios en el proveedor, sospecha primero de la entrada de proveedor antes que del flujo. La cuestión del prefijo Bearer. La clave se envía tal cual bajo el header que elegiste. Los endpoints que requieren el prefijo Bearer literal necesitan tenerlo escrito en el campo de clave; APIsRouter acepta ambas formas, pero si alguna vez reapuntas este proveedor a otro sitio, recuerda que la plataforma no añadirá el prefijo por ti. Los Model IDs son exactos. Un id registrado con una errata pasa el formulario (las etiquetas son texto libre) y falla en tiempo de ejecución con modelo no encontrado; la salida de /v1/models del gateway es la ortografía autorizada. La falta de auto-descubrimiento es una característica, no un fallo. Si falta un modelo en el selector de un flujo, es que no se registró en el proveedor; añádelo en la consola de administración en lugar de buscarlo en el constructor de flujos. Y mantén separadas mentalmente las conexiones a nivel de pieza: piezas individuales como la pieza de OpenAI pueden tener sus propias credenciales por conexión, mientras que la entrada de proveedor descrita aquí alimenta las capacidades de IA universales de la plataforma. Si un flujo usa una pieza específica de un proveedor con su propia conexión, ese tráfico no se enruta a través de tu entrada de gateway.

Quién enruta Activepieces a través de un gateway.

• Equipos autoalojados que estandarizan la IA en docenas de flujos, donde una entrada de proveedor y una clave sustituyen credenciales dispersas por pieza.
• Administradores de plataforma que quieren gobernanza de modelos: una lista de modelos curada, uso por clave, y la capacidad de cambiar el endpoint subyacente sin tocar los flujos.
• Agencias que ejecutan automatizaciones de clientes en una sola instancia, midiendo el uso de IA por cliente con claves separadas sobre el mismo catálogo.
• Creadores cuyos flujos mezclan pasos de volumen y pasos de juicio, combinando ids rápidos con ids de vanguardia por paso a través de un solo endpoint.
• Desarrolladores sin acceso a la facturación de un proveedor concreto. El acceso mediante recarga sin necesidad de tarjeta elimina la dependencia de registrarse en cada proveedor.

Verifica el endpoint y depura el primer paso de IA.

Ejecuta los dos curls de arriba antes de guardar el proveedor; prueban juntos la clave, la Base URL y el id de modelo, que es exactamente lo que el formulario no comprobará por ti. Cuando el paso de IA de un flujo falla tras la configuración, lee el error del paso. Los fallos de autenticación significan que el campo de clave o el nombre de header están mal (o falta el prefijo Bearer en un endpoint que lo requiere). Un error de modelo no encontrado es un id registrado que no coincide con el catálogo. Un error de conexión suele significar que la Base URL perdió su /v1. Si el paso no encuentra ningún modelo que seleccionar, el proveedor se guardó pero la lista de modelos está vacía para ese tipo de modelo. Una vez que los flujos se ejecutan, la consola de APIsRouter muestra el modelo por petición, el recuento de tokens y el gasto. Las automatizaciones programadas se acumulan silenciosamente, y la vista de uso por clave es cómo un administrador de plataforma ve qué flujos se ganan sus tokens antes de que lo haga la factura.

Preguntas frecuentes