Give Activepieces flows an OpenAI-compatible AI provider.

Quick answer: one provider entry in the admin AI setup.

In the Activepieces admin console, open the AI setup page and add a provider of the OpenAI Compatible type. The form takes a Display Name, an API Key, a Base URL, an API Key Header, optional default headers, and a model list where each entry has a Model ID, a Model Name, and a Model Type. The values for APIsRouter: Base URL is https://api.apisrouter.com/v1 (the same shape the codebase uses for its own built-in compatible providers), API Key Header is Authorization, and the key field takes your gateway key. One implementation detail worth knowing: Activepieces sends the key in that header exactly as you typed it, with no Bearer prefix added automatically, so enter it as "Bearer sk-..." for the canonical form; APIsRouter also accepts the bare key in the Authorization header, so either spelling works here. Then add each model you want flows to see, with Model ID matching the catalog exactly.

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

How Activepieces uses a custom provider.

Activepieces (roughly 23K stars on GitHub) is the leading open-source no-code automation platform: flows built from triggers and pieces, in the Zapier shape but self-hostable, with an MIT-licensed piece framework and a large community catalog. Its AI capabilities (text generation steps, agents, AI utility pieces) resolve their model through the platform's configured AI providers, which is what makes the provider entry a routing decision for every flow at once. Under the hood, the OpenAI Compatible provider builds a standard client against your Base URL and attaches your key under the header name you chose, plus per-run metadata headers that identify the project and flow. The Model ID you registered is passed through as the model string on chat-completions requests. There is no model auto-discovery for this provider type: flows can select exactly the models you added to the list, which keeps the picker intentional rather than flooded. Provider configuration is platform-level. An admin defines it once, and every project and flow on the instance selects from the registered models. That centralization is the governance win: one place to decide which models exist, one key to meter all AI steps, and the per-flow metadata in each request making usage attributable when you read the logs.

Full setup and the save-time caveat.

The form saves without validating the connection; the provider implementation explicitly skips connection checks for the OpenAI Compatible type. That is convenient (no probing your endpoint at save time) but it means a wrong Base URL or a malformed key fails later, on the first flow run that touches an AI step. Verify the endpoint by hand once before wiring it into production flows, and treat the first run as part of setup. Model Type matters for what pieces can use the entry: text steps want TEXT models. Register the id exactly as the catalog spells it; the Model Name is a display label and can be anything readable. If you want the same underlying model at two price-performance tiers for different teams, register it once per Model ID; the display names keep them distinguishable in the picker.

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"}]}'

Choosing models for automation steps.

Because the provider is platform-wide, model governance is one screen: add the ids you bless, watch a week of usage per key, and prune what nobody should use. Flow builders keep their freedom inside the list you curated.

• Automation AI is high-volume, short-prompt work: classify a ticket, extract fields, draft a message, summarize a webhook payload. claude-haiku-4-5-20251001, gpt-5.4-mini, and deepseek-v4-flash cover most steps at volume pricing.
• Reserve a stronger id for judgment steps. A flow that drafts customer-facing replies or makes routing decisions earns claude-sonnet-4-6, selected per step in the flow builder.
• MiniMax-M2.7 and the DeepSeek family price extremely well for bulk transformation flows (feeds, scraping cleanups, enrichment) where thousands of runs a day are normal.
• Flows run unattended, so cost is a schedule multiplied by a per-run token count. The usage log gives you the per-run number; the schedule is yours.
• Register few models deliberately. The picker shows exactly what you added, and a curated list keeps a hundred flow builders from each choosing differently.

Pay-as-you-go · transparent per-model pricing

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

Failure modes specific to Activepieces.

Silent save, loud first run. Because the OpenAI Compatible provider skips connection validation, every wiring mistake (wrong Base URL, missing /v1, bad key, wrong header name) surfaces as a failed AI step in a flow run rather than a form error. When an AI step fails right after provider changes, suspect the provider entry before the flow. The Bearer prefix question. The key is sent verbatim under your chosen header. Endpoints that require the literal Bearer prefix need it typed into the key field; APIsRouter accepts both forms, but if you ever repoint this provider elsewhere, remember the platform will not add the prefix for you. Model IDs are exact. A registered id with a typo passes the form (labels are free text) and fails at run time with model-not-found; the gateway's /v1/models output is the authoritative spelling. No auto-discovery is a feature, not a bug. If a model is missing from a flow's picker, it was not registered on the provider; add it in the admin console rather than hunting in the flow builder. And keep piece-level connections separate in your head: individual pieces like the OpenAI piece can hold their own credentials per connection, while the provider entry described here powers the platform's universal AI capabilities. If a flow uses a vendor-specific piece with its own connection, that traffic does not route through your gateway entry.

Who routes Activepieces through a gateway.

• Self-hosting teams standardizing AI across dozens of flows, where one provider entry and one key replace scattered per-piece credentials.
• Platform admins who want model governance: a curated model list, per-key usage, and the ability to swap the backing endpoint without touching flows.
• Agencies running client automations on one instance, metering AI usage per client with separate keys on the same catalog.
• Builders whose flows mix volume steps and judgment steps, pairing fast ids with frontier ids per step through one endpoint.
• Developers without access to a given vendor's billing. Top-up based access with no card requirement removes the per-provider sign-up dependency.

Verify the endpoint and debug the first AI step.

Run the two curls above before saving the provider; they prove the key, the Base URL, and the model id together, which is exactly what the form will not check for you. When a flow's AI step fails after setup, read the step error. Authentication failures mean the key field or header name is wrong (or the Bearer prefix is missing on an endpoint that requires it). A model-not-found error is a registered id that does not match the catalog. A connection error usually means the Base URL lost its /v1. If the step cannot find any model to select, the provider saved but the model list is empty for that model type. Once flows run, the APIsRouter console shows per-request model, token counts, and spend. Scheduled automations compound quietly, and the per-key usage view is how a platform admin sees which flows earn their tokens before the invoice does.

FAQ