תנו לתהליכי Activepieces ספק AI תואם OpenAI.

תשובה מהירה: רשומת ספק אחת בהגדרות ה-AI של הניהול.

בקונסולת הניהול של Activepieces, פתחו את דף הגדרות ה-AI (AI setup) והוסיפו ספק מסוג OpenAI Compatible. הטופס לוקח Display Name, API Key, Base URL, API Key Header, כותרות ברירת מחדל אופציונליות, ורשימת מודלים שבה לכל רשומה יש Model ID, Model Name, ו-Model Type. הערכים עבור APIsRouter: ה-Base URL הוא https://api.apisrouter.com/v1 (אותה צורה שהקוד עצמו משתמש בה עבור הספקים התואמים המובנים שלו), ה-API Key Header הוא Authorization, ושדה המפתח לוקח את מפתח ה-gateway שלכם. פרט מימוש אחד ששווה לדעת: Activepieces שולח את המפתח בכותרת הזו בדיוק כפי שהקלדתם, בלי להוסיף קידומת Bearer אוטומטית, אז הזינו אותו כ-"Bearer sk-..." לצורה הקנונית; APIsRouter מקבל גם את המפתח החשוף בכותרת Authorization, כך ששתי הכתיבות עובדות כאן. לאחר מכן הוסיפו כל מודל שאתם רוצים שהתהליכים יראו, כאשר 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 משתמש בספק מותאם אישית.

Activepieces (כ-23K כוכבים ב-GitHub) היא פלטפורמת האוטומציה ה-no-code הקוד-פתוח המובילה: תהליכים בנויים מ-triggers ו-pieces, בצורה של Zapier אבל ניתנת לאירוח עצמי, עם framework של pieces ברישיון MIT וקטלוג קהילה גדול. יכולות ה-AI שלה (שלבי יצירת טקסט, agents, pieces שירותי AI) פותרות את המודל שלהן דרך ספקי ה-AI המוגדרים בפלטפורמה, וזה מה שהופך את רשומת הספק להחלטת ניתוב לכל תהליך בבת אחת. מתחת למכסה, ספק ה-OpenAI Compatible בונה client סטנדרטי מול ה-Base URL שלכם ומצרף את המפתח שלכם תחת שם הכותרת שבחרתם, בתוספת כותרות metadata לכל הרצה שמזהות את הפרויקט ואת התהליך. ה-Model ID שרשמתם מועבר כמחרוזת המודל בבקשות chat-completions. אין גילוי-מודלים אוטומטי לסוג הספק הזה: תהליכים יכולים לבחור בדיוק את המודלים שהוספתם לרשימה, מה שהופך את הבורר למכוון ולא מוצף. הגדרת הספק היא ברמת הפלטפורמה. מנהל מגדיר אותה פעם אחת, וכל פרויקט ותהליך במופע בוחר מהמודלים הרשומים. הריכוזיות הזו היא הזכייה בממשל: מקום אחד להחליט אילו מודלים קיימים, מפתח אחד למדוד את כל שלבי ה-AI, וה-metadata לכל תהליך בכל בקשה שהופך את השימוש לניתן-לייחוס כשאתם קוראים את הלוגים.

הגדרה מלאה ואזהרת זמן-השמירה.

הטופס נשמר בלי לאמת את החיבור; מימוש הספק מדלג במפורש על בדיקות חיבור עבור סוג ה-OpenAI Compatible. זה נוח (אין בדיקה של ה-endpoint שלכם בזמן השמירה) אבל זה אומר ש-Base URL שגוי או מפתח פגום נכשלים מאוחר יותר, בהרצה הראשונה של תהליך שנוגע בשלב AI. אמתו את ה-endpoint ידנית פעם אחת לפני שאתם מחווטים אותו לתהליכי production, והתייחסו להרצה הראשונה כחלק מההגדרה. Model Type משנה למה pieces יכולים להשתמש ברשומה: שלבי טקסט רוצים מודלי TEXT. רשמו את ה-id בדיוק כפי שהקטלוג מאיית אותו; ה-Model Name הוא תווית תצוגה ויכול להיות כל דבר קריא. אם אתם רוצים את אותו מודל בבסיס בשתי רמות מחיר-ביצועים לצוותים שונים, רשמו אותו פעם אחת לכל 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"}]}'

בחירת מודלים לשלבי אוטומציה.

מכיוון שהספק הוא רחב-פלטפורמה, ממשל המודלים הוא מסך אחד: הוסיפו את ה-ids שאתם מברכים, צפו בשבוע של שימוש לפי מפתח, וגזמו את מה שאף אחד לא צריך להשתמש בו. בוני התהליכים שומרים על החופש שלהם בתוך הרשימה שטיפחתם.

• AI לאוטומציה הוא עבודה בנפח גבוה עם prompt קצר: מיון כרטיס, חילוץ שדות, טיוטת הודעה, סיכום payload של webhook. claude-haiku-4-5-20251001, gpt-5.4-mini, ו-deepseek-v4-flash מכסים את רוב השלבים במחיר נפח.
• שמרו id חזק יותר לשלבי שיפוט. תהליך שמנסח תשובות פונות-ללקוח או מקבל החלטות ניתוב מרוויח claude-sonnet-4-6, נבחר לכל שלב בבונה התהליך.
• MiniMax-M2.7 ומשפחת DeepSeek מתומחרים מצוין לתהליכי טרנספורמציה בכמות גדולה (feeds, ניקוי scraping, העשרה) שבהם אלפי הרצות ביום הן נורמליות.
• תהליכים רצים ללא השגחה, אז העלות היא לוח-זמנים כפול מספר טוקנים להרצה. לוג השימוש נותן לכם את המספר להרצה; לוח הזמנים שלכם.
• רשמו מעט מודלים במכוון. הבורר מציג בדיוק את מה שהוספתם, ורשימה מטופחת שומרת על כך שמאה בוני תהליכים לא יבחרו אחרת כל אחד.

תשלום לפי שימוש · מתחת למחיר הרשמי

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

מצבי כשל ספציפיים ל-Activepieces.

שמירה שקטה, הרצה ראשונה רועשת. מכיוון שספק ה-OpenAI Compatible מדלג על אימות חיבור, כל טעות חיווט (Base URL שגוי, /v1 חסר, מפתח פגום, שם כותרת שגוי) עולה כשלב AI כושל בהרצת תהליך במקום שגיאת טופס. כששלב AI נכשל מיד אחרי שינויי ספק, חשדו ברשומת הספק לפני התהליך. שאלת קידומת ה-Bearer. המפתח נשלח כלשונו תחת הכותרת שבחרתם. endpoints שדורשים את קידומת ה-Bearer המילולית צריכים אותה מוקלדת בשדה המפתח; APIsRouter מקבל את שתי הצורות, אבל אם אי-פעם תכוונו את הספק הזה למקום אחר, זכרו שהפלטפורמה לא תוסיף את הקידומת עבורכם. Model IDs מדויקים. id רשום עם טעות הקלדה עובר את הטופס (תוויות הן טקסט חופשי) ונכשל בזמן ריצה עם model-not-found; פלט /v1/models של ה-gateway הוא האיות הסמכותי. היעדר גילוי-אוטומטי הוא פיצ'ר, לא באג. אם מודל חסר בבורר של תהליך, הוא לא נרשם על הספק; הוסיפו אותו בקונסולת הניהול במקום לחפש בבונה התהליכים. ושמרו את חיבורי רמת ה-piece נפרדים בראש: pieces בודדים כמו ה-OpenAI piece יכולים להחזיק אישורים משלהם לכל חיבור, בעוד רשומת הספק המתוארת כאן מפעילה את יכולות ה-AI האוניברסליות של הפלטפורמה. אם תהליך משתמש ב-piece ספציפי-לספק עם חיבור משלו, התעבורה הזו לא מנותבת דרך רשומת ה-gateway שלכם.

מי מנתב את Activepieces דרך gateway.

• צוותי self-hosting שמאחדים AI על פני עשרות תהליכים, שם רשומת ספק אחת ומפתח אחד מחליפים אישורים מפוזרים לכל piece.
• מנהלי פלטפורמה שרוצים ממשל מודלים: רשימת מודלים מטופחת, שימוש לפי מפתח, והיכולת להחליף את ה-endpoint התומך בלי לגעת בתהליכים.
• סוכנויות שמריצות אוטומציות לקוחות במופע אחד, מודדות שימוש AI לכל לקוח עם מפתחות נפרדים על אותו קטלוג.
• בונים שהתהליכים שלהם מערבבים שלבי נפח ושלבי שיפוט, מצמידים ids מהירים עם ids מתקדמים לכל שלב דרך endpoint אחד.
• מפתחים ללא גישה לחיוב של ספק נתון. גישה מבוססת-הטענה בלי דרישת כרטיס מסירה את התלות בהרשמה לכל ספק.

אמתו את ה-endpoint ובצעו דיבוג לשלב ה-AI הראשון.

הריצו את שני ה-curl למעלה לפני שמירת הספק; הם מוכיחים את המפתח, ה-Base URL, וה-model id ביחד, בדיוק מה שהטופס לא יבדוק עבורכם. כששלב AI של תהליך נכשל אחרי ההגדרה, קראו את שגיאת השלב. כשלי אימות אומרים ששדה המפתח או שם הכותרת שגויים (או שקידומת ה-Bearer חסרה ב-endpoint שדורש אותה). שגיאת model-not-found היא id רשום שלא תואם לקטלוג. שגיאת חיבור בדרך כלל אומרת של-Base URL אבד ה-/v1 שלו. אם השלב לא מוצא מודל לבחור, הספק נשמר אבל רשימת המודלים ריקה עבור סוג המודל הזה. ברגע שהתהליכים רצים, קונסולת APIsRouter מציגה מודל לכל בקשה, ספירות טוקן, והוצאה. אוטומציות מתוזמנות מצטברות בשקט, ותצוגת השימוש לפי-מפתח היא איך מנהל פלטפורמה רואה אילו תהליכים מרוויחים את הטוקנים שלהם לפני שהחשבונית עושה זאת.

שאלות נפוצות