Bigyan ang mga Activepieces flow ng OpenAI-compatible AI provider.

Mabilisang sagot: isang provider entry sa admin AI setup.

Sa Activepieces admin console, buksan ang AI setup page at magdagdag ng provider na OpenAI Compatible ang type. Tumatanggap ang form ng Display Name, isang API Key, isang Base URL, isang API Key Header, opsyonal na default headers, at isang model list kung saan may Model ID, Model Name, at Model Type ang bawat entry. Ang mga value para sa APIsRouter: ang Base URL ay https://api.apisrouter.com/v1 (parehong hugis ang ginagamit ng codebase para sa sarili nitong built-in na compatible providers), ang API Key Header ay Authorization, at ang key field ay kumukuha ng iyong gateway key. Isang implementation detail na dapat malaman: ipinapadala ng Activepieces ang key sa header na iyon eksaktong kung paano mo ito na-type, walang Bearer prefix na awtomatikong idinadagdag, kaya i-type ito bilang "Bearer sk-..." para sa canonical form; tinatanggap din ng APIsRouter ang bare key sa Authorization header, kaya pareho itong gumagana rito. Pagkatapos, idagdag ang bawat model na gusto mong makita ng mga flow, na tumutugma nang eksakto ang Model ID sa katalogo.

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

Paano ginagamit ng Activepieces ang isang custom provider.

Ang Activepieces (humigit-kumulang 23K stars sa GitHub) ang pangunahing open-source no-code automation platform: mga flow na binuo mula sa triggers at pieces, sa hugis ng Zapier pero self-hostable, na may MIT-licensed na piece framework at malaking community catalog. Ang mga AI capability nito (text generation steps, agents, AI utility pieces) ay nire-resolve ang model sa pamamagitan ng mga na-configure na AI provider ng platform, kaya't ang provider entry ay isang routing decision para sa lahat ng flow nang sabay-sabay. Sa ilalim, ang OpenAI Compatible provider ay gumagawa ng standard client laban sa Base URL mo at inilalagay ang key mo sa ilalim ng header name na pinili mo, kasama ang per-run metadata headers na nagpapakilala sa project at flow. Ang Model ID na na-register mo ay ipinapasa bilang model string sa mga chat-completions request. Walang model auto-discovery para sa provider type na ito: pipili lamang ang mga flow mula sa mga model na idinagdag mo sa listahan, na pinapanatiling sinasadya ang picker sa halip na puno ng gulo. Ang provider configuration ay platform-level. Idinedefine ito ng admin nang isang beses, at bawat project at flow sa instance ay pumipili mula sa mga na-register na model. Ang sentralisasyong iyon ang panalo sa governance: isang lugar para magdesisyon kung anong mga model ang umiiral, isang key para sukatin ang lahat ng AI step, at ang per-flow metadata sa bawat request ay ginagawang malinaw ang usage kapag binasa mo ang logs.

Buong setup at ang caveat sa oras ng pag-save.

Nagse-save ang form nang hindi vine-validate ang koneksyon; tahasang nilalaktawan ng provider implementation ang mga connection check para sa OpenAI Compatible type. Maginhawa iyon (walang pag-probe sa endpoint mo sa oras ng pag-save) pero ibig sabihin nito, ang isang maling Base URL o isang sirang key ay mabibigo sa ibang pagkakataon, sa unang flow run na humipo sa isang AI step. I-verify ang endpoint nang manu-mano nang isang beses bago ikabit ito sa mga production flow, at ituring ang unang run bilang bahagi ng setup. Mahalaga ang Model Type para sa magagamit ng mga piece: gusto ng text steps ang TEXT models. I-register ang id nang eksakto kung paano ito binabaybay ng katalogo; ang Model Name ay isang display label lamang at maaaring anumang mababasa. Kung gusto mo ang parehong underlying model sa dalawang price-performance tier para sa iba't ibang team, i-register ito nang isang beses kada Model ID; pinananatili ng display names na magkaiba ang mga ito sa 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"}]}'

Pagpili ng mga model para sa automation steps.

Dahil platform-wide ang provider, isang screen lamang ang model governance: idagdag ang mga id na pinagtitibay mo, obserbahan ang isang linggo ng usage kada key, at putulin ang hindi dapat gamitin ninuman. Napananatili ng mga flow builder ang kanilang kalayaan sa loob ng listahang kinurate mo.

• Ang automation AI ay mataas ang volume, maiikling prompt na trabaho: i-classify ang isang ticket, mag-extract ng fields, mag-draft ng mensahe, i-summarize ang isang webhook payload. Sinasakop ng claude-haiku-4-5-20251001, gpt-5.4-mini, at deepseek-v4-flash ang karamihan ng steps sa volume pricing.
• Maglaan ng mas malakas na id para sa mga judgment step. Ang isang flow na nagdi-draft ng mga sagot na nakikita ng customer o gumagawa ng routing decision ay dapat kunin ang claude-sonnet-4-6, na pinipili per step sa flow builder.
• Napakahusay magpresyo ang MiniMax-M2.7 at ang DeepSeek family para sa bulk transformation flows (feeds, scraping cleanups, enrichment) kung saan normal ang libu-libong run kada araw.
• Tumatakbo ang mga flow nang walang bantay, kaya ang gastos ay isang schedule na pinarami sa isang per-run token count. Ibinibigay ng usage log ang per-run na numero; nasa iyo ang schedule.
• Magparehistro ng kaunting model nang sinasadya. Ipinapakita ng picker eksakto kung ano ang idinagdag mo, at pinapanatili ng isang curated na listahan na hindi magkaiba-iba ang pinipili ng isandaang flow builder.

Pay-as-you-go · mas mababa sa opisyal na presyo

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

Mga failure mode na specific sa Activepieces.

Tahimik na pag-save, maingay na unang run. Dahil nilalaktawan ng OpenAI Compatible provider ang connection validation, bawat pagkakamali sa koneksyon (maling Base URL, kulang na /v1, maling key, maling pangalan ng header) ay lumilitaw bilang isang nabigong AI step sa isang flow run sa halip na form error. Kapag nabigo ang isang AI step pagkatapos lang baguhin ang provider, suspetsahan muna ang provider entry bago ang flow. Ang tanong sa Bearer prefix. Ipinapadala ang key nang literal sa ilalim ng header na pinili mo. Ang mga endpoint na nangangailangan ng literal na Bearer prefix ay kailangan itong i-type sa key field; tinatanggap ng APIsRouter ang dalawang forma, pero kung sakaling i-repoint mo ang provider na ito sa ibang lugar, tandaan na hindi idadagdag ng platform ang prefix para sa iyo. Eksakto ang mga Model ID. Ang isang na-register na id na may typo ay pumapasa sa form (libreng text ang mga label) at nabibigo sa run time gamit ang model-not-found; ang /v1/models output ng gateway ang authoritative na baybay. Ang kawalan ng auto-discovery ay isang feature, hindi bug. Kung may nawawalang model sa picker ng isang flow, hindi ito na-register sa provider; idagdag ito sa admin console sa halip na maghanap sa flow builder. At panatilihing hiwalay sa isip mo ang piece-level connections: ang mga indibidwal na piece tulad ng OpenAI piece ay maaaring humawak ng sariling credentials per connection, habang ang provider entry na inilarawan dito ang nagpapatakbo ng universal na AI capabilities ng platform. Kung gumagamit ang isang flow ng vendor-specific na piece na may sariling connection, hindi dumadaan ang traffic na iyon sa gateway entry mo.

Sino ang nagru-route ng Activepieces sa pamamagitan ng isang gateway.

• Mga self-hosting team na naka-standardize ng AI sa dose-dosenang flow, kung saan pinapalitan ng isang provider entry at isang key ang mga nakakalat na per-piece na credentials.
• Mga platform admin na gustong magkaroon ng model governance: isang curated na model list, per-key usage, at ang kakayahang palitan ang backing endpoint nang hindi hinihipo ang mga flow.
• Mga ahensiyang nagpapatakbo ng client automations sa isang instance, sinusukat ang AI usage per client gamit ang hiwalay na key sa parehong katalogo.
• Mga builder kung saan ang mga flow ay pinaghalo ang volume steps at judgment steps, na ipinares ang mabilis na id sa frontier id per step sa isang endpoint.
• Mga developer na walang access sa billing ng isang partikular na vendor. Ang top-up based na access na walang kailangang card ay inaalis ang per-provider na sign-up dependency.

I-verify ang endpoint at i-debug ang unang AI step.

Patakbuhin ang dalawang curl sa itaas bago i-save ang provider; pinapatunayan nila ang key, ang Base URL, at ang model id na magkasama, na eksaktong hindi che-check ng form para sa iyo. Kapag nabigo ang AI step ng isang flow pagkatapos ng setup, basahin ang step error. Nangangahulugan ang authentication failures na mali ang key field o pangalan ng header (o kulang ang Bearer prefix sa isang endpoint na nangangailangan nito). Ang isang model-not-found na error ay isang na-register na id na hindi tumutugma sa katalogo. Ang isang connection error ay karaniwang nangangahulugan na nawala sa Base URL ang /v1 nito. Kung walang mahanap na model na mapipili ang step, na-save ang provider pero walang laman ang model list para sa model type na iyon. Kapag tumakbo na ang mga flow, ipinapakita ng APIsRouter console ang per-request na model, token counts, at gastos. Tahimik na nag-iipon ang mga scheduled automation, at ang per-key usage view ang paraan ng isang platform admin para makita kung aling mga flow ang karapat-dapat sa kanilang mga token bago pa dumating ang invoice.

Mga madalas itanong