به flow های Activepieces یک AI provider سازگار با OpenAI بدهید.

پاسخ سریع: یک entry provider در AI setup ادمین.

در کنسول ادمین Activepieces، صفحه AI setup را باز کنید و یک provider از نوع OpenAI Compatible اضافه کنید. فرم یک Display Name، یک API Key، یک Base URL، یک API Key Header، header های پیش‌فرض اختیاری، و یک فهرست مدل می‌گیرد که هر entry آن یک Model ID، یک Model Name، و یک Model Type دارد. مقادیر برای APIsRouter: Base URL برابر https://api.apisrouter.com/v1 است (همان شکلی که خود codebase برای provider های compatible داخلی‌اش استفاده می‌کند)، API Key Header برابر Authorization است، و فیلد کلید، کلید gateway شما را می‌گیرد. یک جزئیات پیاده‌سازی که ارزش دانستن دارد: Activepieces کلید را دقیقاً همان‌طور که تایپ کرده‌اید زیر آن header می‌فرستد، بدون افزودن خودکار پیشوند Bearer، پس آن را برای شکل canonical به‌صورت «Bearer sk-...» وارد کنید؛ APIsRouter کلید بدون پیشوند در header Authorization را هم می‌پذیرد، پس هر دو نگارش اینجا کار می‌کند. سپس هر مدلی که می‌خواهید flow ها ببینند را اضافه کنید، با Model ID که دقیقاً با کاتالوگ مطابقت دارد.

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

Activepieces چطور از یک provider سفارشی استفاده می‌کند.

Activepieces (حدود ۲۳ هزار ستاره در GitHub) پلتفرم اتوماسیون no-code متن‌باز پیشرو است: flow هایی ساخته‌شده از trigger ها و piece ها، در شکل Zapier اما self-hostable، با یک framework piece دارای مجوز MIT و یک کاتالوگ community بزرگ. قابلیت‌های AI آن (گام‌های تولید متن، agent ها، piece های utility AI) مدل خود را از طریق AI provider های پیکربندی‌شده پلتفرم resolve می‌کنند، که همین باعث می‌شود entry provider یک تصمیم مسیردهی برای همه flow ها هم‌زمان باشد. زیر پوسته، provider OpenAI Compatible یک client استاندارد در برابر Base URL شما می‌سازد و کلید شما را زیر نام header ای که انتخاب کرده‌اید متصل می‌کند، به‌علاوه header های metadata هر-اجرا که پروژه و flow را شناسایی می‌کنند. Model ID ای که ثبت کرده‌اید به‌عنوان رشته model در درخواست‌های chat-completions عبور داده می‌شود. برای این نوع provider auto-discovery مدل وجود ندارد: flow ها می‌توانند دقیقاً همان مدل‌هایی را انتخاب کنند که به فهرست اضافه کرده‌اید، که انتخاب‌گر را عمدی نگه می‌دارد نه سرریز. پیکربندی provider در سطح پلتفرم است. یک ادمین آن را یک‌بار تعریف می‌کند، و هر پروژه و flow روی instance از مدل‌های ثبت‌شده انتخاب می‌کند. آن تمرکز، برد governance است: یک جا برای تصمیم اینکه کدام مدل‌ها وجود دارند، یک کلید برای اندازه‌گیری همه گام‌های AI، و metadata هر-flow در هر درخواست که usage را هنگام خواندن log ها قابل‌انتساب می‌کند.

راه‌اندازی کامل و نکته save-time.

فرم بدون تأیید اتصال ذخیره می‌شود؛ پیاده‌سازی provider به‌صراحت چک‌های اتصال را برای نوع OpenAI Compatible رد می‌کند. این راحت است (بدون کاوش endpoint شما هنگام ذخیره) اما یعنی یک Base URL اشتباه یا یک کلید بدشکل بعداً، در اولین اجرای flow که یک گام AI را لمس می‌کند، شکست می‌خورد. endpoint را یک‌بار دستی تأیید کنید قبل از سیم‌کشی آن در flow های production، و اولین اجرا را بخشی از راه‌اندازی در نظر بگیرید. Model Type برای اینکه piece ها چه چیزی می‌توانند از entry استفاده کنند اهمیت دارد: گام‌های متنی مدل‌های TEXT می‌خواهند. id را دقیقاً همان‌طور که کاتالوگ می‌نویسد ثبت کنید؛ Model Name یک برچسب نمایشی است و می‌تواند هر چیز خوانا باشد. اگر می‌خواهید همان مدل زیرین را در دو tier قیمت-عملکرد برای تیم‌های مختلف داشته باشید، آن را یک‌بار به ازای هر Model ID ثبت کنید؛ نام‌های نمایشی آن‌ها را در انتخاب‌گر قابل‌تمایز نگه می‌دارند.

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

انتخاب مدل‌ها برای گام‌های اتوماسیون.

چون provider سطح-پلتفرم است، governance مدل یک صفحه است: id هایی که تأیید می‌کنید اضافه کنید، یک هفته usage به ازای هر کلید را تماشا کنید، و آنچه نباید کسی استفاده کند را هرس کنید. سازندگان flow آزادی خود را داخل فهرستی که curate کرده‌اید حفظ می‌کنند.

• AI اتوماسیون کار حجم‌بالا و prompt-کوتاه است: طبقه‌بندی یک ticket، استخراج فیلدها، پیش‌نویس یک پیام، خلاصه‌سازی payload یک webhook. claude-haiku-4-5-20251001، gpt-5.4-mini، و deepseek-v4-flash بیشتر گام‌ها را با قیمت‌گذاری حجمی پوشش می‌دهند.
• یک id قوی‌تر را برای گام‌های قضاوتی نگه دارید. flow ای که پاسخ‌های مشتری‌محور را پیش‌نویس می‌کند یا تصمیم‌های مسیریابی می‌گیرد claude-sonnet-4-6 را می‌طلبد، انتخاب‌شده به ازای هر گام در flow builder.
• MiniMax-M2.7 و خانواده DeepSeek برای flow های تبدیل حجمی (feed ها، پاکسازی scraping، enrichment) که هزاران اجرا در روز عادی است، قیمت فوق‌العاده‌ای دارند.
• flow ها بدون‌نظارت اجرا می‌شوند، پس هزینه یک زمان‌بندی ضرب‌شده در شمار token هر-اجراست. usage log عدد هر-اجرا را می‌دهد؛ زمان‌بندی مال شماست.
• مدل‌های کمی را عمداً ثبت کنید. انتخاب‌گر دقیقاً همان چیزی را نشان می‌دهد که اضافه کرده‌اید، و یک فهرست curated جلوی این را می‌گیرد که صد سازنده flow هرکدام چیز متفاوتی انتخاب کنند.

پرداخت بر اساس مصرف · پایین‌تر از قیمت رسمی

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

حالت‌های شکست مختص Activepieces.

save بی‌صدا، اولین اجرای پرسروصدا. چون provider OpenAI Compatible تأیید اتصال را رد می‌کند، هر اشتباه سیم‌کشی (Base URL اشتباه، /v1 گمشده، کلید بد، نام header اشتباه) به‌جای خطای فرم، به‌عنوان یک گام AI شکست‌خورده در یک اجرای flow ظاهر می‌شود. وقتی یک گام AI درست بعد از تغییرات provider شکست می‌خورد، قبل از flow به entry provider شک کنید. سؤال پیشوند Bearer. کلید عیناً زیر header انتخابی شما فرستاده می‌شود. endpoint هایی که پیشوند لفظی Bearer را الزامی می‌کنند نیاز دارند آن در فیلد کلید تایپ شود؛ APIsRouter هر دو شکل را می‌پذیرد، اما اگر روزی این provider را جای دیگری هدایت کنید، به‌خاطر بسپارید پلتفرم پیشوند را برای شما اضافه نمی‌کند. Model ID ها دقیق‌اند. یک id ثبت‌شده با غلط‌تایپی از فرم عبور می‌کند (برچسب‌ها متن آزادند) و در زمان اجرا با model-not-found شکست می‌خورد؛ خروجی /v1/models گیت‌وی نگارش معتبر است. نبود auto-discovery یک feature است نه یک باگ. اگر یک مدل از انتخاب‌گر یک flow غایب است، روی provider ثبت نشده؛ آن را در کنسول ادمین اضافه کنید به‌جای شکار در flow builder. و اتصال‌های سطح-piece را در ذهن جدا نگه دارید: piece های مجزا مثل piece OpenAI می‌توانند credential های خود را به ازای هر اتصال نگه دارند، در حالی که entry provider توضیح‌داده‌شده اینجا قابلیت‌های AI جهانی پلتفرم را تغذیه می‌کند. اگر یک flow از یک piece مختص-vendor با اتصال خودش استفاده کند، آن ترافیک از entry gateway شما عبور نمی‌کند.

چه کسانی Activepieces را از طریق یک gateway مسیردهی می‌کنند.

• تیم‌های self-hosting که AI را در ده‌ها flow استاندارد می‌کنند، جایی که یک entry provider و یک کلید credential های پراکنده هر-piece را جایگزین می‌کنند.
• ادمین‌های پلتفرم که governance مدل می‌خواهند: یک فهرست مدل curated، usage هر-کلید، و توانایی سوییچ endpoint پشتیبان بدون لمس flow ها.
• آژانس‌هایی که اتوماسیون‌های مشتری را روی یک instance اجرا می‌کنند، AI usage را به ازای هر مشتری با کلیدهای جدا روی همان کاتالوگ اندازه‌گیری می‌کنند.
• سازندگانی که flow های آن‌ها گام‌های حجمی و گام‌های قضاوتی را ترکیب می‌کنند، id های سریع را با id های frontier به ازای هر گام از طریق یک endpoint جفت می‌کنند.
• توسعه‌دهندگان بدون دسترسی به صورت‌حساب یک vendor خاص. دسترسی مبتنی بر شارژ بدون الزام کارت وابستگی ثبت‌نام هر-provider را حذف می‌کند.

endpoint را تأیید کنید و اولین گام AI را عیب‌یابی کنید.

دو curl بالا را قبل از ذخیره provider اجرا کنید؛ آن‌ها کلید، Base URL، و model id را با هم اثبات می‌کنند، دقیقاً همان چیزی که فرم برای شما چک نمی‌کند. وقتی گام AI یک flow بعد از راه‌اندازی شکست می‌خورد، خطای گام را بخوانید. شکست‌های authentication یعنی فیلد کلید یا نام header اشتباه است (یا پیشوند Bearer روی endpoint ای که آن را الزامی می‌کند گمشده). یک خطای model-not-found یک id ثبت‌شده است که با کاتالوگ مطابقت ندارد. یک خطای اتصال معمولاً یعنی Base URL /v1 خود را گم کرده. اگر گام هیچ مدلی برای انتخاب پیدا نکند، provider ذخیره شده اما فهرست مدل برای آن نوع مدل خالی است. وقتی flow ها اجرا شوند، کنسول APIsRouter مدل، شمارش token، و هزینه هر-درخواست را نشان می‌دهد. اتوماسیون‌های زمان‌بندی‌شده بی‌صدا انباشته می‌شوند، و نمای usage هر-کلید روشی است که یک ادمین پلتفرم می‌بیند کدام flow ها token هایشان را قبل از صورت‌حساب کسب می‌کنند.

پرسش‌های پرتکرار