---
sidebar:
  order: 1
title: ממשק API ב־HTTP
description: בצעו אימות זהות, גלו כלים ואשרו שינויים דרך ממשק ה־API הקיים ב־HTTP.
---

שלחו בקשות לממשק ה־API של המוצר אל כתובת המקור המהימנה שלכם ב־Influence, למשל `https://influence.so`. דומיין התיעוד אינו מקבל בקשות לממשק ה־API של המוצר. השתמשו בנתיבים המדויקים שלמטה, ללא פרמטרים בשאילתה.

## יצירת מפתח API עם הרשאות מוגדרות [#create-a-scoped-api-key]

ב[הגדרות Influence](https://influence.so/sign-in?next=%2Fapp%2Fsettings%2Faccount%23settings-developer), פתחו את אפליקציות ואוטומציות ואז את מפתחות API. בחרו את ההרשאות הדרושות ותאריך תפוגה. שמרו את המפתח שמוצג פעם אחת בלבד במאגר הסודות שלכם בשם `PUBLISH_API_TOKEN`. שלחו אותו ב־`Authorization: Bearer …`; לעולם אל תכללו אותו בכתובת URL, בגוף בקשה או בצ׳אט. בטלו אותו כשאין בו עוד צורך.

## גילוי כלים וקריאת חשבונות [#discover-tools-and-make-a-read]

הגדירו את `PUBLISH_API_URL` לכתובת המקור המהימנה. הדוגמאות האלה מניחות ש־`PUBLISH_API_TOKEN` כבר זמין לתהליך שלכם. `accountList` דורש `integrations:read`; פעלו לפי שדות הדפדוף שלו כדי לקבל עמודים נוספים.

```sh
export PUBLISH_API_URL="https://influence.so"
curl "$PUBLISH_API_URL/api/v1/tools" \
  -H "Authorization: Bearer $PUBLISH_API_TOKEN"

curl "$PUBLISH_API_URL/api/v1/tools/accountList/call" \
  -H "Authorization: Bearer $PUBLISH_API_TOKEN" \
  -H 'Content-Type: application/json' \
  --data '{"input":{}}'
```

## נתיבי הבקשות [#request-paths]

| שיטה | נתיב | מטרה |
| --- | --- | --- |
| `GET` | `/api/v1/tools` | הצגת הכלים שזמינים לפרטי הגישה האלה. |
| `POST` | `/api/v1/tools/{tool}/call` | קריאה לכלי שאינו דורש אישור, כולל המשך העלאות שכבר ניתנה הרשאה לביצוען. |
| `POST` | `/api/v1/tools/{tool}/prepare` | הכנת פעולת כתיבה מדויקת ללא ביצועה. |
| `POST` | `/api/v1/tools/{tool}/confirm` | אישור פעולת הכתיבה שהוכנה. |
| `POST` | `/api/v1/media/import` | אישור העלאה בינארית מוכנה של תמונה קטנה. |

בקשות JSON לכלים משתמשות ב־`Content-Type: application/json` ובגוף שמכיל רק `input`: `{"input":{…}}`. קבלו את סכמת הקלט של כל כלי מקטלוג הכלים העדכני.

## הכנה ואישור של פעולות [#prepare-and-confirm-actions]

השתמשו בשדה `confirmation` בקטלוג: קריאות נתונים לרוב אינן דורשות אישור, אבל רענון תובנות דורש אישור אף שהוא פעולת קריאה. איתור חלקי העלאה, השלמה וביטול ממשיכים העלאה שכבר ניתנה הרשאה לביצועה דרך `/call`.

1. שלחו את הקלט העסקי המדויק אל `/prepare`. תגובה שהצליחה כוללת `status: "confirmation_required"`, `confirmationCapability`, `expiresAt`, `inputDigest` וייתכן שגם `summary`.
2. לפני פקיעת התוקף, שלחו את אותו קלט אל `/confirm`. כללו את ערך האישור שהוחזר ב־`X-Publish-Confirmation` ומפתח חדש שנוצר בצד הלקוח ב־`Idempotency-Key`.
3. שמרו יחד את הקלט, ערך האישור והמפתח. לאחר אישור שנקטע או שתוצאתו אינה ודאית, השתמשו שוב בכל 3 הערכים לאותה בקשה. אל תכינו בקשה חלופית כדי להתאושש מתוצאה לא ודאית.

מפתח אידמפוטנטיות מכיל 16–200 תווים מתוך `A–Z`, `a–z`, `0–9`, `.`, `_`, `:` ו־`-`. ערכי האישור הם סודות אטומים. מפתח שנשלח אל `/call` או `/prepare` אינו שומר מקום לפעולת כתיבה מאושרת.

אישור ברמת התעבורה נפרד מאישור לפרסום. לפרסום או לשינוי תזמון, הציגו את הבדיקה העדכנית המלאה: חשבונות, טקסט, הגדרות, תצוגות מקדימות או קישורים למדיה עצמה, מועד מתוזמן ואזור זמן. הלקוח יכול לדווח על אישור אנושי מפורש חדש באמצעות `approval: "approved"` לבדיקות מתאימות של פוסטים ברשתות חברתיות עם טקסט, תמונות וסרטונים; אסור לו להמציא הסכמה או להתייחס להכנה כאישור. Influence מתעדת זאת כאישור שדווח על ידי הלקוח. כרטיס מוטמע נתמך או בדיקה לאחר כניסה לחשבון מתעדים את הפעולה האנושית שבוצעה בהם.

TikTok Direct מקבל בחירות והסכמה מפורשות בצ׳אט דרך [תהליך הבדיקה](/he/developers/mcp#prepare-finished-content). שמרו את הבחירות המלאות באמצעות `campaignReview`, ואז קבלו אישור חדש לבדיקה המעודכנת לפני הביצוע. כרטיס בדיקה אינו חובה. תזמון רגיל דרך ה־API או ה־CLI אינו מנצל את מכסת התזמון בעזרת בינה מלאכותית; [מכסת MCP ו־Influence IQ](/he/help/ai-assistants#scheduling-allowance) הנפרדת חלה על תהליכי העבודה האלה גם כשבדיקת בינה מלאכותית שמורה מאושרת מאוחר יותר ב־Influence. דרישות אחרות של התוכנית והספק עדיין חלות. קראו את רשומת התוצאה השמורה לפני פעולה נוספת; `needs_review` דורש בירור והתאמה, לא שליחה נוספת.

## טיפול בשגיאות ובתוצאות לא ודאיות [#handle-errors-and-uncertain-results]

בדקו גם את סטטוס ה־HTTP וגם את גוף התגובה. כלים שהצליחו מחזירים `{"ok":true,"toolName":"…","output":{…}}`. כשלי כלים מחזירים `{"ok":false,"toolName":"…","error":{"code":"…","message":"…","retryable":false}}` ויכולים להגיע בקוד HTTP 200. כשלי תעבורה משתמשים ב־`{"error":{"code":"…","message":"…","retryable":false}}`, ללא `ok` או `toolName`.

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

## העלאת מדיה [#upload-media]

לקבצים מקומיים, העדיפו את `uploadMedia` של ה־SDK או את `media:upload` של ה־CLI. הם משתמשים באותם כלי העלאה מסוג multipart ושומרים על `clientKey` קבוע לניסיונות חוזרים. אפשר לצרף רק תוצאה מוכנה עם `assetId`. לקישור HTTPS מורשה, השתמשו ב־`mediaImport` עם `url` ו־`name` לבחירה. הפניות אמיתיות לקבצים במארח משתמשות באובייקט `file` הנפרד; כתובת URL ציבורית אינה דורשת מזהה קובץ מומצא מהמארח. נתיב קובץ מקומי אינו כתובת URL להורדה. ראו [מגבלות מדיה](/he/help/media): ייבוא וידאו ב־HTTPS מוגבל ל־250 MiB, גם כשאפשר להעלות ישירות קובץ MP4 מוכן וגדול יותר.

`POST /api/v1/media/import` תומך בתעבורה הקיימת לתמונות קטנות: הכינו `mediaImport` עם מתאר ההעלאה המדויק, ואז שלחו את אותם בתים כ־`application/octet-stream`. כללו `X-Publish-Confirmation`, `Idempotency-Key` ו־`X-Publish-Upload` שמכיל את מתאר ה־JSON לאחר קידוד URI. הבתים חייבים להתאים לגודל ול־SHA-256 שבמתאר. התעבורה הזאת מוגבלת ל־3 MiB; השתמשו בכלי העזר להעלאה לקבצים נתמכים גדולים יותר. העלאה לעולם אינה מאשרת פרסום.

[עיינו במפרט ה־API](/he/api-reference) או [הורידו את מפרט OpenAPI](/specs/influence.openapi.json).
