Cloudways API – איך יוצרים טוקן ומנהלים שרתים אוטומטית

עודכן לאחרונה: 07.11.2026 · מאת עשהאל דרייר

בקצרה: Cloudways API מאפשר לנהל שרתים ואפליקציות בקלאודוויז (Cloudways) מתוך קוד, סקריפט או כלי אוטומציה. הדרך המומלצת היא Access Token במקום מפתח ה-API הישן: בתפריט הפרופיל בוחרים API Integration, לוחצים Create Access Token, בוחרים שם, תוקף והרשאות (Limited, Read-Only או Full), ומעתיקים את הטוקן, שמוצג פעם אחת בלבד. רק בעל החשבון הראשי יכול ליצור טוקנים, ומגבלת הקצב היא 100 בקשות לדקה.

⏱ זמן ביצוע: כ-10 דקות ליצירת טוקן ובדיקה ראשונה · רמת קושי: בינונית (מיועד למפתחים ולסוכנויות) · נבדק לאחרונה: 07.11.2026 (קריאות API אמיתיות מ-6.11.2026)

מה זה Cloudways API ולמה צריך אותו?

API הוא ממשק שדרכו תוכנה מדברת עם תוכנה אחרת. במקום ללחוץ בפאנל, הסקריפט שלכם שולח בקשה (למשל "הצג את רשימת השרתים" או "נקה קאש באפליקציה"), וקלאודוויז מבצעת ומחזירה תשובה ב-JSON.

למי זה שימושי? לסוכנויות שמקימות אתרים ללקוחות בתבנית קבועה, למפתחים שרוצים פריסה אוטומטית מ-Git, ולמי שבונה דשבורד ניטור או דוח חודשי לכל השרתים. גם שרת ה-MCP של קלאודוויז, שמחבר עוזרי AI לחשבון, עובד על בסיס אותם טוקנים. אם המושג MCP חדש לכם, קראו מה זה MCP.

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

נושא	מפתח API הישן	Access Token
סטטוס	הוצא משימוש; לפי קלאודוויז סוף החיים נקבע ל-15.10.2026	השיטה הנוכחית
כמה אפשר ליצור	מפתח אחד לחשבון	כמה שצריך, אחד לכל אינטגרציה
הרשאות	גישה מלאה לחשבון	Limited, Read-Only או Full
תוקף	ללא	יום, חודש, 3 חודשים, חצי שנה, שנה או Never
ביטול	החלפת מפתח שוברת את כל האינטגרציות	Revoke לטוקן אחד בלבד

איזו רמת הרשאה לבחור לטוקן?

העיקרון שקלאודוויז ממליצה עליו הוא "הרשאה מינימלית": לתת לכל אינטגרציה רק את מה שהיא חייבת.

Scope	מה מותר	מתי לבחור
Read-Only Access	רק קריאה (בקשות GET): רשימות, פרטי שרת, ניטור	דשבורדים, דוחות, כלי ניטור
Limited Access (Beta)	רק קבוצות ופעולות שבחרתם, למשל Server, Application, Git, Monitoring, Services, Lists, App Management	רוב האינטגרציות, למשל סקריפט פריסה שצריך רק Git
Full Access	כל הפעולות: יצירה, שינוי ומחיקה	רק כשבאמת צריך הכול, ורק במערכת שאתם סומכים עליה

לפני שמתחילים

• היכנסו עם בעל החשבון הראשי. חברי צוות לא רואים את API Integration ולא יכולים ליצור טוקנים, גם עם הרשאות מלאות.
• הכינו מקום בטוח לשמירת הטוקן: מנהל סיסמאות, משתנה סביבה או כספת סודות.
• החליטו מראש מה האינטגרציה צריכה לעשות, כדי לבחור את ההרשאות המתאימות.

איך יוצרים Access Token ל-Cloudways API? שלב אחר שלב

1. היכנסו לפאנל הניהול, פתחו את תפריט הפרופיל בפינה הימנית העליונה ובחרו API Integration.
2. באזור Access Token Details לחצו Create Access Token.
3. ב-Access Token Name כתבו שם שמסביר איפה הטוקן ישמש, למשל "Monitoring Dashboard" או "Staging Deployment Script".
4. ב-Expiration בחרו את התקופה הקצרה ביותר שמספיקה. התאריך המדויק יוצג מתחת לבחירה.
5. ב-Scope בחרו Limited Access, Read-Only Access או Full Access. ב-Limited, סמנו קטגוריות או פעולות בודדות, ואפשר לחפש לפי שם.
6. לחצו Create Access Token. הכפתור לא פעיל עד שממלאים שם, תוקף והרשאות.
7. במסך Access Token Created לחצו על סמל ההעתקה ושמרו את הטוקן מיד במקום בטוח.
8. סמנו I have successfully copied the Access Token ולחצו Done.

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

איך שולחים את הבקשה הראשונה? Playground ו-curl

הדרך הבטוחה להכיר את ה-API היא ה-API Playground, ממשק בדפדפן שבו מריצים כל פעולה ורואים את התשובה.

1. פתחו את אתר ה-API של קלאודוויז (developers.cloudways.com) ובחרו Playground.
2. לחצו Authorize, עברו ללשונית Access Token, הדביקו את הטוקן ולחצו Authorize.
3. פתחו פעולת קריאה פשוטה, למשל רשימת השרתים, והריצו אותה.

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

מקוד: לפי מפרט ה-OpenAPI הרשמי באתר המפתחים של קלאודוויז, האימות הוא מסוג Bearer: שולחים את הטוקן בכותרת Authorization, מול הכתובת https://api.cloudways.com/api/v2/. כך נראית בקשה לרשימת השרתים (בלי טוקן אמיתי, רק משתנה סביבה):

curl -H "Authorization: Bearer $CW_TOKEN" \
  https://api.cloudways.com/api/v2/servers

שמרו את הטוקן במשתנה סביבה (כאן CW_TOKEN) ולא בתוך הקוד. הנתיב server/ בלי s מסומן בתיעוד כמוצא משימוש, ולכן הדוגמה משתמשת ב-servers. טוקן לא תקין יחזיר 401. את המבנה המדויק של כל פעולה, הפרמטרים והתשובות, בדקו בתיעוד ה-API, שהוא המקור המחייב.

מה אפשר לעשות עם ה-API

קטגוריה	דוגמאות לשימוש
Lists	ספקי ענן, אזורים, גדלי שרת וערכים לבחירה
Server ו-Server Management	הקמת שרת, פרטי שרת, הגדלה, הגדרות וניטור שימוש
Service	הפעלה, עצירה והפעלה מחדש של Apache, Nginx, PHP-FPM ו-MySQL
Application ו-App Management	יצירת אפליקציה, גיבוי, דומיינים, Cron ו-SSL
Git	חיבור מאגר, משיכת שינויים ופריסה אוטומטית
Projects	ארגון שרתים ואפליקציות בפרויקטים
Security	ניהול רשימות IP מותרות וחסומות
CloudwaysBot	התראות, ערוצים והעדפות התראה

מגבלת הקצב היא 100 בקשות לדקה. סקריפט שעובר על הרבה שרתים צריך לכלול השהיה קצרה בין בקשות ולטפל בתשובות שגיאה.

איך בדקנו דרך ה-API באילו ספקים יש שרת בתל אביב?

ב-6.11.2026 קראנו ל-GET /api/v1/regions, שמחזיר את כל האזורים של כל ספק ענן בקלאודוויז. התוצאה: תל אביב זמינה ב-AWS (il-central-1), ב-Google Cloud (me-west1) וב-Vultr (tlv). ל-DigitalOcean ול-Linode אין אזור בישראל.

זו דוגמה טובה לשימוש ב-API: התשובה מגיעה ישר מהמערכת שמקימה את השרתים, ולכן היא עדכנית יותר ממאמרי עזרה. בפועל, אחד ממאמרי ה-KB של קלאודוויז עדיין לא מציג את תל אביב ברשימת המיקומים של Vultr, וה-API כן.

הבקשה ששלחנו

השתמשנו בשיטת האימות הישנה, כי היא זו שהייתה מוגדרת אצלנו: קודם מקבלים טוקן OAuth זמני מהאימייל וממפתח ה-API, ואז שולחים אותו ככותרת Bearer. פרטי הגישה נמצאים במשתני סביבה ולא בקוד:

# 1. טוקן זמני מהאימייל וממפתח ה-API (השיטה הישנה)
curl -s -X POST https://api.cloudways.com/api/v1/oauth/access_token \
  --data-urlencode "email=$CW_EMAIL" \
  --data-urlencode "api_key=$CW_API_KEY"
# התשובה כוללת access_token; שמרו אותו ב-CW_OAUTH

# 2. רשימת האזורים
curl -s -H "Authorization: Bearer $CW_OAUTH" \
  https://api.cloudways.com/api/v1/regions

עם Access Token חדש מדלגים על שלב 1 ושולחים את הטוקן ישר בכותרת Authorization, כמו בדוגמה הקודמת. לפי מפרט ה-OpenAPI, אותה פעולה קיימת גם בגרסה 2 בנתיב /regions.

מבנה התשובה (מקוצר)

התשובה היא אובייקט regions עם מפתח לכל ספק, ובו מערך של אזורים עם id ו-name. קיצרנו והשארנו רק את מה שרלוונטי לישראל:

{
  "regions": {
    "amazon": [ …, { "id": "il-central-1", "name": "…" }, … ],
    "gce":    [ …, { "id": "me-west1",     "name": "…" }, … ],
    "vultr":  [ …, { "id": "tlv",          "name": "…" }, … ],
    "do":     [ … 10 אזורים, אף אחד בישראל … ],
    "linode": [ … 26 אזורים, אף אחד בישראל … ]
  }
}

כדי לראות רק את האזורים הישראליים, אפשר לסנן עם jq:

curl -s -H "Authorization: Bearer $CW_OAUTH" \
  https://api.cloudways.com/api/v1/regions \
  | jq '.regions | map_values(map(select(.id | test("il-central-1|me-west1|tlv"))))'

ספק (מפתח ב-API)	תל אביב?	מזהה האזור	אימות מול הספק
AWS (amazon)	כן	il-central-1	Israel (Tel Aviv) ברשימת האזורים של AWS
Google Cloud (gce)	כן	me-west1	me-west1 בתל אביב לפי Google Cloud
Vultr (vultr)	כן	tlv	tlv, Tel Aviv ב-API הציבורי של Vultr
DigitalOcean (do)	לא	–	10 אזורים, אף אחד בישראל
Linode (linode)	לא	–	26 אזורים, אף אחד בישראל

נכון ל-6.11.2026, לפי קריאת ה-API שלנו. רוצים להבין מה זה אומר על מהירות ומחיר? ראו המדריך לשרת בתל אביב, ואת המדריכים לכל ספק: AWS תל אביב, Google Cloud תל אביב ו-Vultr תל אביב.

רשימת השרתים: GET /api/v1/server

את רשימת השרתים בחשבון מושכים עם GET /api/v1/server, באותה כותרת Bearer. כל שרת חוזר עם המזהה, השם, הספק, האזור, ה-IP ורשימת האפליקציות שעליו. כך נראה המבנה, עם ערכים מוסתרים:

{
  "status": true,
  "servers": [
    {
      "id": "XXXXXX",
      "label": "my-server",
      "status": "running",
      "cloud": "vultr",
      "region": "…",
      "public_ip": "0.0.0.0",
      "apps": [ { "id": "…", "label": "…", "application": "wordpress", … } ]
    }
  ]
}

שימו לב לשני דברים. הראשון: לפי מפרט ה-OpenAPI, הנתיב /server מסומן כמוצא משימוש, כי הוא מחזיר את כל השרתים והאפליקציות בלי חלוקה לעמודים. בקוד חדש השתמשו ב-/servers של גרסה 2. השני: לפי הדוגמה במפרט, התשובה יכולה לכלול גם סיסמאות (של משתמש ה-master, של האפליקציות ושל מסדי הנתונים). אל תשמרו אותה בלוגים, אל תדביקו אותה בצ'אט, ואל תפרסמו IP או מזהי שרת, כמו שגם אנחנו לא עשינו כאן.

איך מנהלים ומבטלים טוקנים קיימים?

הטבלה Access Token Details מציגה לכל טוקן את השם, ההרשאות (Scopes), מתי נוצר, מתי שימש לאחרונה (Last Used) ומתי פג תוקפו. מתפריט שלוש הנקודות בשורה:

• Edit: שינוי ההגדרות הזמינות, כמו שם, תוקף והרשאות. שינוי השם לא משנה את ערך הטוקן.
• View Scopes: לטוקנים מסוג Limited, רשימת הפעולות המותרות.
• Revoke: ביטול לצמיתות. מאשרים ב-Revoke Key, וכל אינטגרציה שמשתמשת בטוקן מפסיקה לעבוד מיד.
• Reveal Credentials: מתג לכל טוקן, שקובע אם סיסמאות SSH ו-SFTP יכולות להופיע בתוצאות של שרת ה-MCP. כברירת מחדל הוא כבוי, והשאירו אותו כך אלא אם יש סיבה.

טיפ מהשטח: עברו על העמודה Last Used פעם ברבעון. טוקן שלא שימש חודשים הוא כנראה שארית מפרויקט שהסתיים, ועדיף לבטל אותו.

עברתם ממפתח ה-API הישן? מה צריך לבדוק?

מפתח ה-API הישן (אימייל ומפתח, שהומרו לטוקן זמני דרך oauth/access_token) הוצא משימוש. לפי מאמר הטוקנים של קלאודוויז, סוף החיים שלו נקבע ל-15 באוקטובר 2026, ואחריו המפתחות יבוטלו ואינטגרציות שמשתמשות בהם עלולות להפסיק לעבוד.

מה ראינו בפועל: ב-6.11.2026, שלושה שבועות אחרי התאריך, הקריאות שלנו עם המפתח הישן מול api/v1 עדיין עבדו (ראו הדוגמה למעלה). זה לא אומר שזה ימשיך. התייחסו לזה כחלון חסד שיכול להיסגר בלי הודעה, ועברו לטוקנים עכשיו.

1. רשמו כל מקום שבו המפתח הישן שימש: סקריפטים, Webhooks של Git, כלי ניטור, חיבורי MCP.
2. צרו Access Token נפרד לכל אחד, עם ההרשאות שהוא צריך.
3. החליפו את המפתח בטוקן, ובדקו שהאינטגרציה עובדת.
4. מחקו את המפתח הישן מכל קובצי התצורה.

בחיבור MCP, הכותרות הישנות X-CW-Email ו-X-CW-Api-Key הוחלפו בכותרת X-Access-Token. פירוט במדריך Cloudways MCP. לשימוש מעשי בניהול אתר באמצעות AI ראו ניהול אתר וורדפרס עם Claude ו-ChatGPT.

טעויות נפוצות ואיך לפתור אותן

אין לי API Integration בתפריט: אתם מחוברים כחבר צוות. רק בעל החשבון הראשי יכול לגשת ל-API.

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

הפעולה נדחית למרות שהטוקן תקין: להרשאה שבחרתם אין גישה לפעולה. בדקו ב-View Scopes, או צרו טוקן Limited עם הקטגוריה החסרה.

שגיאות אחרי הרבה בקשות: עברתם את מגבלת 100 הבקשות לדקה. הוסיפו השהיה ונסו שוב.

טוקן נשמר ב-Git: בטלו אותו מיד ב-Revoke, גם אם המאגר פרטי, וצרו חדש. מחיקת הקובץ לא מוחקת אותו מהיסטוריית הקומיטים.

שאלות נפוצות

מדריכים קשורים

• Cloudways MCP – ניהול השרת עם עוזר AI
• איך להשתמש ב-Cloudways Copilot
• Cloudways Autonomous
• SafeUpdates – עדכונים בטוחים לוורדפרס
• שרת בתל אביב בקלאודוויז: כל האפשרויות
• מיקומי השרתים של קלאודוויז
• כל המדריכים בתחום: AI ואוטומציה בקלאודוויז
• הסקירה המלאה: אחסון אתרים בקלאודוויז

מקורות

• How to Create and Manage Cloudways API Access Tokens – Cloudways Knowledge Base
• Cloudways API (OpenAPI) – נתיבי /regions, /server ו-/servers, נבדק 07.11.2026
• AWS Regions – AWS
• Regions and zones – Google Cloud
• Vultr API: regions – Vultr
• קריאות API שלנו: GET /api/v1/regions, 6.11.2026 (חשבון cw-servers.co.il)

מקור רשמי: How to Create and Manage Cloudways API Access Tokens (Cloudways Knowledge Base) · Cloudways API Playground · Cloudways API (OpenAPI). המדריך נכתב ונבדק על ידי עשהאל דרייר · עודכן: 07.11.2026

גילוי נאות: זהו אתר עצמאי ואינו האתר הרשמי של Cloudways. חלק מהקישורים באתר הם קישורי שותפים – אם תירשמו דרכם נקבל עמלה, בלי עלות נוספת לכם. לפרטים המלאים