מעבר ל-Chronicle API

נתמך ב:

במסמך הזה מפורטים השלבים והשיקולים שיעזרו לכם לעדכן את ההפניות הפרוגרמטיות ל-API לנקודות הקצה של SOAR API כחלק מ-Chronicle API.

ב-Chronicle API יש כמה שיפורים שנועדו לייעל את תהליך הפיתוח. הוא גם נותן מענה למגבלות ולמורכבויות שקיימות ב-API הישן.

הגרסה הקודמת של SOAR API ומפתחות ה-API תמשיך לפעול עד 31 במרץ 2027.

שילובים מוכנים מראש של תגובות

אם אתם משתמשים בגרסת שילוב מיושנת שקוראת לממשקי ה-API הקודמים של SOAR, עדכנו את חבילת השילוב לפני 31 במרץ 2027:

  • שילובים של Content Hub: פותחים את Content Hub ב-Google Security Operations ומעדכנים את כל השילובים המסחריים המיושנים לגרסאות העדכניות שלהם. מידע נוסף זמין במאמר סקירה כללית של Content Hub.
  • תוסף Splunk: אם אתם משתמשים בתוסף Chronicle SOAR ל-Splunk, שדרגו את TA-Siemplify ב-Splunk לגרסה העדכנית. אחרי השדרוג, מגדירים מחדש את התוסף כך שישתמש בנקודת הקצה האזורית של Chronicle API ובפרטי הכניסה של Google Cloud חשבון השירות.

דרישות מוקדמות

לפני שמעבירים את הקריאות ל-SOAR API אל Chronicle API, צריך להשלים את שלב 1 של ההעברה (Google.com מופיע לצד גרסת המערכת בהגדרות SOAR > ניהול רישיונות). אתם יכולים לבדוק ולהעביר קריאות פרוגרמטיות ל-Chronicle API לפני או אחרי שתפעילו את Google Cloud ניהול הזהויות והרשאות הגישה (IAM) לקבוצות ההרשאות של SOAR.

שינויים ושיפורים מרכזיים

בטבלה הבאה מפורטים ההבדלים העיקריים בין ממשקי ה-API הישנים והחדשים:

אזור התכונה Old API API חדש פרטים
אימות טוקן API OAuth 2.0 שיטת האימות החדשה מספקת אבטחה משופרת והופכת את התהליך לאחיד.
מודלים של נתונים מבנים שטוחים עיצוב מבוסס-משאבים העיצוב החדש משפר את העקביות של הנתונים ומפשט את הטיפול באובייקטים.
מתן שמות לנקודות קצה (endpoint) לא עקבי RESTful וסטנדרטי מתן שמות עקביים הופך את ה-API לאינטואיטיבי יותר וקל יותר לשילוב.

לוח הזמנים להוצאה משימוש

ממשק ה-API הקודם של siemplify-soar.com והאימות של AppKey יישארו זמינים עד 31 במרץ 2027, ואז הם יפסיקו לפעול.

עד 31 במרץ 2027, ממשקי ה-API הקודמים של SOAR ימשיכו לפעול במקביל ל-Chronicle API, גם אחרי שתפעילו את Google Cloud IAM. כך תוכלו להעביר ולאמת בהדרגה כל רכיב בקצב שלכם, בלי להפריע לתהליכי העבודה הפעילים.

ממשק ה-API הקודם של SOAR פחות יעיל מ-Chronicle API, ולכן מומלץ לעבור לתחליפים של Chronicle API בהקדם האפשרי, ולפני 31 במרץ 2027, כדי למנוע שיבושים בשירות.

שלבי ההעברה

בקטע הזה מפורטים השלבים לשדרוג האפליקציות ל-Chronicle API:

עיון במסמכי התיעוד

כדאי לעיין במסמכי התיעוד המקיפים של ה-API החדש, כולל במדריך העזר של Chronicle API.

מיפוי נקודות קצה לממשק ה-API החדש

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

אופציונלי: יצירת שילוב בסביבת Staging

אם אתם עורכים שילוב בהתאמה אישית או פעולה בהתאמה אישית, Google ממליצה להעביר קודם את השינויים לשילוב בסביבת Staging. התהליך הזה מאפשר לכם לבצע בדיקות בלי להשפיע על תהליכי האוטומציה בסביבת הייצור. אם אתם מעבירים אפליקציה בהתאמה אישית שמשתמשת ב-SOAR API, אתם יכולים לדלג לשלב הבא. במאמר בדיקת שילובים במצב Staging מוסבר איך לבדוק את השילובים.

עדכון נקודת הקצה (endpoint) וכתובות ה-URL של השירות

נקודת קצה של שירות היא כתובת ה-URL הבסיסית שמציינת את כתובת הרשת של שירות API. לשירות אחד יכולות להיות כמה נקודות קצה. ‫Chronicle הוא שירות אזורי, ולכן הוא תומך רק בנקודות קצה אזוריות.

כל נקודות הקצה החדשות משתמשות בתחילית עקבית, כך שכתובת נקודת הקצה הסופית צפויה. בדוגמה הבאה מוצג המבנה החדש של כתובת ה-URL של נקודת הקצה:

[api_version]/projects/[project_id]/locations/[location]/instances/[instance_id]/...

המבנה הזה יוצר את הכתובת הסופית לנקודת הקצה באופן הבא:

https://[service_endpoint]/[api_version]/projects/[project_id]/locations/[location]/instances/[instance_id]/...

כאשר:

  • ‫service_endpoint: כתובת של שירות אזורי
  • ‫api_version: גרסת ה-API שרוצים לשלוח אליה שאילתה. צריך להשתמש ב-v1 כשהוא זמין, או לחזור ל-v1beta או ל-v1alpha אם v1 עדיין לא זמין (אפשר לבדוק בטבלת המיפוי של SOAR API את הגרסה שנתמכת בכל נקודת קצה).
  • ‫project_id: מזהה הפרויקט (אותו פרויקט שהגדרתם להרשאות IAM)
  • ‫location: המיקום של הפרויקט (אזור), זהה לנקודות הקצה האזוריות
  • ‫instance_id: מזהה הלקוח ב-Google Security Operations SIEM.

כתובות אזוריות:

  • africa-south1: https://africa-south1-chronicle.googleapis.com

  • ‫asia-northeast1: ‏https://asia-northeast1-chronicle.googleapis.com

  • ‫asia-south1:‏ https://asia-south1-chronicle.googleapis.com

  • asia-southeast1: https://asia-southeast1-chronicle.googleapis.com

  • ‫asia-southeast2: https://asia-southeast2-chronicle.googleapis.com

  • ‫australia-southeast1: https://australia-southeast1-chronicle.googleapis.com

  • europe-west12: https://europe-west12-chronicle.googleapis.com

  • europe-west2: https://europe-west2-chronicle.googleapis.com

  • europe-west3: https://europe-west3-chronicle.googleapis.com

  • ‫europe-west6:‏ https://europe-west6-chronicle.googleapis.com

  • europe-west9: https://europe-west9-chronicle.googleapis.com

  • me-central1: https://me-central1-chronicle.googleapis.com

  • me-central2: https://me-central2-chronicle.googleapis.com

  • me-west1: https://me-west1-chronicle.googleapis.com

  • northamerica-northeast2: https://northamerica-northeast2-chronicle.googleapis.com

  • southamerica-east1: https://southamerica-east1-chronicle.googleapis.com

  • us: https://us-chronicle.googleapis.com

  • eu: https://eu-chronicle.googleapis.com

לדוגמה, כדי לקבל רשימה של כל בקשות התמיכה בפרויקט בארה"ב:

GET
  https://us-chronicle.googleapis.com/v1/projects/my-project-name-or-id/locations/us/instances/408bfb7b-5746-4a50-885a-50a323023529/cases

עדכון שיטת האימות

‫Chronicle API משתמש ב- Google Cloud IAM לאימות. כדי להטמיע את תהליך האימות הזה, צריך לעדכן את השילובים בהתאמה אישית או את האפליקציות החיצוניות. מוודאים שלמשתמש או לחשבון השירות שמריץ את הסקריפט יש את ההרשאות הנדרשות לנקודות הקצה (endpoint) הרלוונטיות. מידע נוסף זמין במאמר אימות ל-Chronicle API.

מיפוי חשבון השירות או Workload Identity לפרמטרים של SOAR

אם אתם משתמשים בחשבון שירות או באיחוד שירותי אימות הזהות של עומסי עבודה כדי לאמת את Chronicle API, אתם צריכים לאשר אותו בפלטפורמה כדי לוודא שהוא יכול לתקשר עם Google SecOps. המיפוי הזה נדרש כדי לספק לחשבון השירות או לזהות של עומס העבודה את הגישה הנדרשת לתפקידים ולסביבות של SOC.

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

  1. עוברים אל הגדרות > ניהול גישה > מיפוי קבוצות.
  2. לוחצים על סמל ההוספה הוספה.

  3. ממלאים את השדות בתיבת הדו-שיח Add Mapping כדי למפות את הזהות לפרמטרים של בקרת הגישה של הפלטפורמה.

    1. בשדה IdP / User group, מזינים אחת מהאפשרויות הבאות:
      • כתובת האימייל המלאה של חשבון השירות, אם הזהות הוגדרה באמצעות Cloud Identity.
      • מחרוזת החשבון הראשי של Workload Identity, אם הזהות הוגדרה באמצעות איחוד שירותי אימות הזהות של כוח העבודה.

    2. מגדירים את השדות הבאים של בקרת הגישה:

      שדה תיאור
      קבוצות הרשאות בוחרים את קבוצות ההרשאות כדי להגדיר לאילו מודולים ומודולי משנה הזהות יכולה לגשת.
      תפקידים ב-SOC בוחרים את תפקידי ה-SOC כדי להגדיר את תפקיד הזהות (למשל, רמה 1).
      סביבות בוחרים את הסביבות או את קבוצות הסביבות שהזהות יכולה לגשת אליהן (למשל, כל הסביבות).
      חברי הקבוצה אם רלוונטי, מזינים את כתובות האימייל של המשתמשים הנדרשים. אחרי שמוסיפים כל כתובת אימייל, לוחצים על Enter.
      פעולות מוגבלות כדי להגביל פעולות ספציפיות במודולים, בוחרים את הפעולות המוגבלות.

  4. לוחצים על הוספה.

למידע מפורט יותר על מיפוי משתמשים וחשבונות שירות, קראו את המאמרים מיפוי משתמשים בפלטפורמה באמצעות זהות של צד שלישי או מיפוי משתמשים בפלטפורמה באמצעות Cloud Identity.

עדכון הלוגיקה של ה-API

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

העברת קריאות ל-API בהתאמה אישית ל-Chronicle API

לא כל קוד Python בהתאמה אישית ב-Google SecOps דורש שינויים בקוד:

  • לא צריך לשנות את הקוד של ה-methods המובנות ב-SDK: אם יש לכם קוד Python מותאם אישית בשילובים, בפעולות של פלייבוקים, במחברים ובמשימות שמשתמשים ב-methods מובנות סטנדרטיות ב-SDK (כמו siemplify.add_comment(),‏ siemplify.get_case_comments() או siemplify.update_alerts_additional_data()), אתם לא צריכים לשנות את הקוד. מערכת Google SecOps מנתבת באופן אוטומטי את השיטות המובנות של ה-SDK של Siemplify דרך ממשק ה-API המאוחד.
  • צריך לעדכן רק בקשות HTTP ידניות: צריך לעדכן רק סקריפטים מותאמים אישית של Python שיוצרים באופן ידני בקשות HTTP לממשקי API מדור קודם של SOAR באמצעות מאפייני SDK. לדוגמה, יצירת כתובת URL עם siemplify.API_ROOT ואימות באמצעות siemplify.api_key באמצעות requests או siemplify.session. כדי לזהות רכיבים בהתאמה אישית שמושפעים מהשינוי, מריצים את resource.labels.namespace_name="chronicle-soar" AND labels.auth_deprecation="true" AND labels.is_custom="true" ב-Logs Explorer (בודקים את labels.integration_name,‏ labels.action_name,‏ labels.connector_name,‏ labels.job_name ו-labels.playbook_name), או בודקים את הרשימה CustomCode בדוח סיכום השימוש ב-API מדור קודם.

בדיקת השילוב

לפני שמעבירים את האפליקציה המעודכנת לסביבת הייצור, בודקים אותה בסביבת בדיקה:

  1. יצירת תוכנית בדיקה: מגדירים מקרי בדיקה שכוללים את כל הפונקציות שהועברו.
  2. מבצעים בדיקות: מריצים בדיקות אוטומטיות וידניות כדי לוודא שהנתונים מדויקים ותקינים.
  3. מעקב אחרי הביצועים: בודקים את הביצועים של האפליקציה עם ה-API החדש.

מכסות והגבלות קצב של יצירת בקשות

ב-Chronicle API נאכפות מכסות ברמת הפרויקט ב- Google Cloud כדי לשמור על זמינות השירות ולמנוע תנועה בלתי מבוקרת:

  • מכסות ברירת מחדל: ב-Chronicle API נאכפות מגבלות של בקשות לדקה (RPM) ברמת הפרויקט Google Cloud – בדרך כלל 6,000 בקשות לדקה לכל פרויקט, עם מגבלות משנה אזוריות ל-API.
  • שגיאות של הגבלת קצב של יצירת בקשות (HTTP 429): אם שילוב או סקריפט חיצוני חורגים ממכסת הפרויקט, Chronicle API מחזיר את הערך HTTP 429 (RESOURCE_EXHAUSTED או TooManyRequestsException).

כדי לראות את השימוש הנוכחי במכסה של Chronicle API או לבקש להגדיל את המגבלה:

  1. במסוף Google Cloud , נכנסים לדף IAM & Admin ‏> Quotas & System Limits:

    כניסה לדף Quotas & System Limits

  2. לוחצים על Filter, בוחרים באפשרות Service ומזינים את הערך chronicle.googleapis.com כדי לבדוק את השימוש הנוכחי ואת המגבלות. איך רואים את המכסות במסוף Google Cloud ?

  3. אם אתם צריכים מכסות גבוהות יותר כדי להטמיע את המערכת בסביבת הייצור, להשתמש באוטומציה או לשלב אותה עם מערכת לניהול כרטיסי מידע, סמנו את התיבה לצד המכסה הרלוונטית ולחצו על Edit (או Edit Quotas) כדי לבקש להגדיל אותה. איך שולחים בקשה לשינוי המכסות אתם יכולים גם לשלוח בקשה להגדלת המכסה דרך Cloud Customer Care או דרך נציג Google SecOps.

בדיקת השימוש שנותר ב-API הקודם

אתם יכולים לזהות את הקריאות שנותרו ל-SOAR API הקודם באמצעות Logging, התראות מערכת בתוך המוצר או נקודת הקצה של סיכום השימוש ב-API הקודם.

רישום שאילתות ביומן

אזהרות לגבי הוצאה משימוש של ממשקי API מדור קודם (labels.auth_deprecation="true") מונפקות כיומנים תפעוליים של SOAR ברמת החומרה WARNING בקטע resource.labels.namespace_name="chronicle-soar" (ראו איסוף יומנים של פלטפורמת SOAR), ולא ביומני הביקורת של Cloud. רק אזהרות שדורשות פעולה מצד הלקוח (labels.actionable_by="Customer") מיוצאות לפרויקט ב- Google Cloud . קריאות פנימיות למערכת ולממשק המשתמש של Google מסוננות באופן אוטומטי.

מריצים את השאילתות הבאות ב-Logs Explorer:

  • שיוך לסוכן מרוחק (labels.is_remote="true"): מציין שיחות בשיטה הקודמת של Meet מקוד שפועל בסוכן מרוחק. קודם כל, משדרגים את הסוכן המרוחק לגרסה 2.6.2 ואילך ומעבירים אותו לאימות של חשבון שירות (ראו העברת תשתית האימות של הסוכן המרוחק). אחרי שמשדרגים את הסוכן המרוחק ומגדירים אותו עם חשבון שירות של Google Cloud , הסקר של מישור הבקרה של הסוכן משתמש ב-OAuth 2.0. שיוך מלא של תוויות רכיבים לקריאות של Remote Agent SDK מושק בשלבים בסביבת הייצור. אם הרשומות ממשיכות להופיע אחרי העברת הנציג, צריך לבדוק אם יש שילובים מיושנים או קוד בהתאמה אישית שפועל בנציג הזה.

  • בדיקת השלמה של אפס יומנים למשך 30 יום (כל השיחות בגרסה הקודמת של Meet שניתן לבצע בהן פעולות של לקוחות):

    resource.labels.namespace_name="chronicle-soar"
labels.auth_deprecation="true"

    העברת ה-API הושלמה כשהשאילתה הזו מחזירה אפס יומנים במשך 30 ימים רצופים.

  • סקריפטים חיצוניים וכלים של צד שלישי שקוראים ישירות לממשקי API מדור קודם (AppKey):

    resource.labels.namespace_name="chronicle-soar"
labels.auth_deprecation="true"
labels.is_system="false"

    השדות שנפלטים כוללים את labels.app_key (המזהה של מפתח ה-API הקודם), את labels.via_xlb ("true" לכניסה חיצונית) ואת נתיב ה-HTTP שנקרא ב-textPayload (Deprecated direct AppKey authentication detected (Route: ROUTE).).

  • שילובים מיושנים של Content Hub: כדי לבדוק אם שילובים מסחריים מותקנים עדיין קוראים לממשקי API מדור קודם של SOAR, מריצים את השאילתה הבאה כדי להציג רשימה של רשומות הוצאה משימוש תואמות (ראו שילובים מוכנים מראש של תגובות):

    resource.labels.namespace_name="chronicle-soar"
labels.auth_deprecation="true"
labels.is_system="true"
labels.is_custom="false"
    תוצאות השאילתה ב-Logs Explorer, שבהן מופיעות רשומות של הוצאה משימוש של שילוב מסחרי מיושן.
    איור 1. תוצאות השאילתה ב-Logs Explorer, שבהן מופיעות רשומות של הוצאה משימוש של שילוב מסחרי מיושן.

    מרחיבים את רשומת היומן התואמת כדי לראות את labels.integration_name, labels.integration_version, labels.latest_integration_version ואת הרכיב שהפעיל את האירוע (labels.action_name, labels.connector_name, labels.job_name או labels.playbook_name):

    רשומת יומן מורחבת של הוצאה משימוש ב-Logs Explorer, שבה מוצגות הגרסאות המותקנות והגרסאות המסחריות העדכניות של השילוב.
    איור 2. רשומה מורחבת ביומן ההוצאה משימוש, שבה מוצגות הגרסה המותקנת והגרסה העדכנית של השילוב המסחרי.

    אפשר גם לבדוק את הרשימה של OutdatedIntegrations בדוח הסיכום של השימוש ב-API מדור קודם.

  • קוד Python בהתאמה אישית שמבצע קריאות HTTP ידניות: מריצים את resource.labels.namespace_name="chronicle-soar" AND labels.auth_deprecation="true" AND labels.is_custom="true" (ראו העברת קריאות ל-API בהתאמה אישית ל-Chronicle API).

בדיקת התראות המערכת בתוך המוצר

כשהיכולת הזו תהיה זמינה במכונות של Google SecOps, בהתראות המערכת יוצג סיכום של קריאות ל-API מדור קודם שניתן לבצע בהן פעולות של לקוחות מ-24 השעות האחרונות, בשילובים מיושנים של Content Hub, ברכיבי IDE מותאמים אישית ובמפתחות API חיצוניים, בדומה לדוגמה הבאה:

Non-1P API usage summary (last 24h): 2294 legacy API call(s) require action.
Content Hub - Update 1 outdated integration(s): GoogleChronicle (v94->v98).
IDE - Refactor 15 custom component(s): Action 'CustomAction' (LegacyAuthCases),
Connector 'CustomConnector' (LegacyAuthCases), Job 'CustomJob'
(LegacyAuthCases) (+12 more).
Settings > API Keys - Migrate 1 external key(s) to 1P auth:
'example_external_automation_key'.

שליחת שאילתה לנקודת הקצה של סיכום השימוש ב-API הקודם

אפשר גם לשלוח שאילתה ישירות אל GET /api/external/v1/logging/non-1p-api-usage כדי לאחזר דוח JSON מצטבר של קריאות ל-API מהדור הקודם שבוצעו לאחרונה:

  1. בהגדרות SOAR > מתקדם > מפתחות API, יוצרים או בוחרים מפתח API מדור קודם שמוקצה לקבוצת הרשאות שכוללת את ההרשאה הגדרות. הוראות מפורטות זמינות במאמר אימות ל-SOAR API מדור קודם.

  2. שולחים בקשת GET עם הכותרת AppKey (מגדירים את hoursBack בין 1 ל-168; ברירת המחדל היא 24):

    curl -H "AppKey: API_KEY" \
  "https://INSTANCE.siemplify-soar.com/api/external/v1/logging/non-1p-api-usage?hoursBack=24"

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

  • ‫OutdatedIntegrations: מציג רשימה של שילובים מסחריים של Content Hub שבהם InstalledVersion ישן יותר מ-LatestVersion, כולל IntegrationName,‏ InstalledVersion,‏ LatestVersion,‏ ActionNeeded,‏ InvocationCount,‏ FirstUsedTimestamp,‏ LastUsedTimestamp ורכיבים מושפעים (AffectedActions,‏ AffectedConnectors,‏ AffectedJobs,‏ AffectedPlaybooks), בדומה לדוגמה הבאה:

    {
  "OutdatedIntegrations": [
    {
      "IntegrationName": "GoogleChronicle",
      "InstalledVersion": "94",
      "LatestVersion": "98",
      "ActionNeeded": "Upgrade integration to v98 in Content Hub",
      "AffectedActions": ["Ping"],
      "AffectedConnectors": ["Google Chronicle - Chronicle Alerts Connector"],
      "InvocationCount": 202,
      "FirstUsedTimestamp": "2026-10-14T19:16:31Z",
      "LastUsedTimestamp": "2026-10-14T19:44:54Z"
    }
  ]
}

  • ‫CustomCode: מציג רכיבי SDK מותאמים אישית (ComponentType: Action,‏ Connector,‏ Job,‏ Playbook או Custom Script) שמבצעים קריאות ידניות ל-API מדור קודם, כולל ComponentName,‏ IntegrationName,‏ AffectedPlaybooks,‏ RoutesUsed,‏ InvocationCount,‏ FirstUsedTimestamp ו-LastUsedTimestamp.

  • ‫DirectAppKeys: מציג קריאות AppKey חיצוניות ישירות שבוצעו מחוץ ל-SDK, כולל AppKey,‏ ActionNeeded,‏ RoutesUsed,‏ InvocationCount,‏ FirstUsedTimestamp ו-LastUsedTimestamp, בדומה לדוגמה הבאה:

    {
  "DirectAppKeys": [
    {
      "AppKey": "example_external_automation_key",
      "ActionNeeded": "Migrate external script or automation to use Google Cloud service account or OAuth authentication",
      "RoutesUsed": [
        "GET /api/external/v1/cases/GetCaseFullDetails/14",
        "GET /api/external/v1/dynamic-cases/GetCaseDetails/14",
        "GET /api/external/v1/ide/GetIdeItemCards",
        "GET /api/external/v1/jobs/GetInstalledJobs",
        "GET /api/external/v1/jobs/GetJobHistoryLogs/jobIdStr",
        "GET /api/external/v1/logging/non-1p-api-usage",
        "GET /api/external/v1/playbooks/GetWorkflowFullInfoWithEnvFilterByIdentifier/00000000-0000-0000-0000-000000000000",
        "POST /api/external/v1/ide/GetIdeItem",
        "POST /api/external/v1/ide/TestItem",
        "POST /api/external/v1/integrations/GetOptionalIntegrationInstances",
        "POST /api/external/v1/jobs/RunJob",
        "POST /api/external/v1/playbooks/AttacheWorkflowToCase",
        "POST /api/external/v1/playbooks/GetWorkflowMenuCardsWithEnvFilter",
        "POST /api/external/v1/playbooks/RerunPlaybook"
      ],
      "InvocationCount": 1084,
      "FirstUsedTimestamp": "2026-10-14T19:30:15.169684Z",
      "LastUsedTimestamp": "2026-10-14T20:24:13.552893800Z"
    }
  ]
}

  • TopOffenders (TopAppKeys ו-TopRoutes): סיכום של הזהויות מדור קודם AppKey ונתיבי ה-HTTP (שיטת HTTP ונתיב) הנפוצים ביותר, כדי לעזור לכם לתעדף את עבודת ההעברה.

הבעיה עדיין לא נפתרה? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.