שאלות נפוצות

בקטע הזה מפורטות תשובות לשאלות נפוצות בנושא הרשמה כמפתח ב-Merchant API.

הרשמה כללית

שאלות נפוצות לגבי תהליך ההרשמה:

האם חובה להירשם כמפתח כדי להשתמש ב-Merchant API?

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

אם אתם רק רוצים לבדוק את Merchant API, אתם יכולים להשתמש בכלים כמו Google OAuth Playground ו-API Explorer שלא דורשים הרשמה.

באיזו תדירות צריך להירשם?

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

אחרי שרושמים פרויקט בענן ב-Google Cloud, הקישור נשאר פעיל אלא אם מסירים אותו באופן מפורש באמצעות הקריאה לשיטה unregisterGcp. אי אפשר לרשום פרויקטים משותפים בבעלות Google, כמו APIs Explorer או OAuth Playground.

איזו כתובת אימייל צריך לציין ככתובת ליצירת קשר עם המפתח?

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

אם כתובת האימייל שייכת למשתמש קיים בחשבון Merchant Center, הוא מקבל באופן אוטומטי את התפקיד API developer. אם לא, תישלח הזמנה לכתובת הזו.

השדה של כתובת האימייל של המפתח הוא אופציונלי בשיטה registerGcp. אם לא תספקו ערך בשדה הזה במהלך ההרשמה, תצטרכו ליצור משתמש עם התפקיד API developer בממשק המשתמש של Merchant Center או באמצעות קריאה לשיטה accounts.users.create.

האם כתובת האימייל של איש הקשר של המפתח צריכה להיות חשבון Google?

כן. כדי להשתמש בכתובת אימייל קיימת שלא שייכת ל-Google, אפשר לשייך אותה לחשבון Google. לשם כך, בוחרים באפשרות שימוש בכתובת האימייל הקיימת בתהליך ההרשמה ליצירת חשבון Google. אי אפשר להשתמש בכתובות אימייל של חשבונות שירות, כי חשבונות שירות לא יכולים לקבל אימיילים.

איך מבצעים אימות והרשאה לקריאה לרישום?

יש שני תרחישי אימות שונים לאימות ולהרשאה של קריאת ההרשמה, בהתאם לתרחיש לדוגמה:

  • ‫OAuth 2.0: לספקי צד שלישי או לסוכנויות שמנהלים כמה חשבונות של מוֹכרים
  • חשבונות שירות: לגישה לחשבון Merchant Center שלכם

טקסט חלופי לנגישות

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

  • שימוש ב-OAuth עם כתובת אימייל כמו account@email.com שמשויכת לחשבון Google
  • שימוש בחשבון שירות כמו sa@project.iam.gserviceaccount.com

אם תבחרו ב-OAuth:

  • יצירת פרטי כניסה ל-OAuth בפרויקט בענן של Google עבור האימייל
  • מוודאים שכתובת האימייל שדרכה נותנים הרשאה קיימת בחשבון Merchant Center ושהוגדר לה סוג הגישה ADMIN.

אם תבחרו להשתמש בחשבון שירות:

  • מוודאים שחשבון השירות קיים בפרויקט Google Cloud
  • מוודאים שכתובת האימייל שמשויכת לחשבון השירות קיימת בחשבון Merchant Center ושיש לה את סוג הגישה ADMIN

מבצעים את קריאת הרישום בהקשר האבטחה של זהות האימות, באמצעות קריאות ישירות ל-API או ספריות לקוח. צריך לספק כתובת אימייל ליצירת קשר עם המפתח, לדוגמה developer@email.com.

אם קריאת הרישום תתבצע בהצלחה, משתמש יתווסף לחשבון Merchant Center עם כתובת האימייל של המפתח שצוינה ותפקיד API developer. תקבלו בתגובה משאב DeveloperRegistration.

מה ההבדל בין האימייל לאימות לבין כתובת האימייל ליצירת קשר עם מפתח?

לשתי כתובות האימייל יש מטרות שונות במערכת האקולוגית של Merchant API:

  • אימות האימייל: בדרך כלל משתמשים בכתובת אימייל שמשויכת לחשבון Google או לחשבון שירות כזהות לאישור בקשות ל-Merchant API, בתנאי שמתקיימים התנאים הבאים:
    • הוא קיים בחשבון Merchant Center שלכם, ויש לו את התפקיד ADMIN.
    • פרויקט ב-Google Cloud שבו מופעל Merchant API מארח את לקוח OAuth או את חשבון השירות שמשויך לכתובת האימייל שמאשרת את הקריאות ל-API.
  • כתובת אימייל ליצירת קשר עם המפתח: כתובת האימייל ליצירת קשר עם המפתח צריכה להיות משויכת לחשבון Google, אבל היא משמשת כאיש קשר ראשי לקבלת הודעות חשובות על שירותים ועדכונים ב-API מ-Google. הוא יכול להיות שייך למשתמש או לקבוצת משתמשים. כברירת מחדל, הוא מקבל את התפקיד API developer ב-Merchant Center.

האם צריך לאשר את ההזמנה שנשלחה לכתובת האימייל של איש הקשר של המפתח?

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

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

למה ההרשמה שלי כפיתוח נכשלת עם השגיאה 'חשבון בדיקה'?

ההרשמה כמפתח מוגבלת לחשבונות פעילים (בסביבת הייצור) כדי להבטיח יציבות בשילוב. אם אתם משתמשים בחשבון שנוצר במיוחד לצורך בדיקות ומסומן כ'חשבון בדיקה' ב-Merchant Center, הרישום יידחה.

האם אפשר לרשום חשבון משני שאני מנהל בשביל לקוח?

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

האם צריך לתבוע בעלות על האתר או רק לאמת אותו?

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

ניהול חשבונות ופרויקטים

שאלות נפוצות בנושא ניהול החשבון והפרויקט:

יש לי כמה חשבונות Merchant Center. האם צריך לרשום כל חשבון Merchant Center שרוצים להשתמש בו עם Merchant API?

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

יש לי כמה חשבונות Merchant Center. איך בוחרים את חשבון Merchant Center הראשי

הבחירה בחשבון הראשי לשימוש תלויה בסוג העסק:

  • זירות מסחר עם חשבון מתקדם קיים: אם העסק שלכם פועל כזירת מסחר וכבר יש לו חשבון מתקדם שמייצג את הפלטפורמה כולה, אתם יכולים להשתמש במספר החשבון הקיים הזה כחשבון Merchant Center הראשי.
  • שירותי השוואת מחירים (CSS): אם אתם שירות CSS, השתמשו במזהה הייחודי של חשבון ה-CSS או במזהה של קבוצת חשבונות CSS.
  • סוכנויות, מפתחים וצדדים שלישיים אחרים: אם אתם עסק צד שלישי כמו סוכנות או מפתח צד שלישי שמנהל כמה חשבונות של מוֹכרים ואין לכם מספר חשבון Merchant Center יחיד שמייצג את העסק שלכם, אתם צריכים ליצור חשבון Merchant Center ראשי חדש ולבקש להמיר אותו לחשבון מתקדם.

אחרי שרושמים את פרויקט הענן ב-Google Cloud בחשבון הראשי של Merchant Center, אפשר להשתמש באותו פרויקט כדי לנהל כל חשבון אחר ב-Merchant Center שיש לכם גישה אליו, בלי לרשום את החשבונות האלה בנפרד.

יש לי כמה פרויקטים ב-Google Cloud. האם צריך לרשום כל אחד מהם?

כן. תהליך הרישום מקשר את פרויקט Google Cloud שממנו מתבצעת הקריאה, ולכן צריך לבצע את הקריאה registerGcp מכל פרויקט ב-Google Cloud שמשמש לביצוע קריאות ל-API.

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

מה קורה אם רושמים פרויקט ב-Google Cloud בכמה חשבונות Merchant Center?

ניסיון לרשום פרויקט בענן ב-Google Cloud שכבר רשום בחשבון אחר ב-Merchant Center יגרום לשגיאה ALREADY_REGISTERED.

איך מאמתים את הקריאה ל-API של רישום מפתחים?

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

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

כדי שההרשמה של מפתח תתבצע בהצלחה, הזהות המאומתת (חשבון Google או חשבון שירות) צריכה לעמוד בקריטריונים הבאים ב-Merchant Center:

  • הכתובת קיימת כמשתמש ב-Merchant Center: כתובת האימייל שמשויכת לחשבון Google או לחשבון השירות שדרכו מתבצע האימות צריכה להיות כתובת של משתמש שנוסף לחשבון Merchant Center שאתם רושמים.
  • נדרשת הרשאת אדמין: למשתמש הזה צריך להיות מוקצה התפקיד ADMIN בחשבון Merchant Center הספציפי.

כשמבצעים קריאות ל-API:

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

יכול להיות שהמשתמש המאמת לא יהיה זהה למשתמש איש הקשר של המפתח. מידע נוסף זמין במאמר מה ההבדל בין כתובת האימייל לאימות לבין כתובת האימייל ליצירת קשר עם המפתח?

באיזו תדירות צריך לרענן את אסימוני הגישה?

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

  • חשבונות שירות משתמשים במפתח פרטי או בפרטי כניסה לסביבה כדי ליצור אסימון גישה חדש כשצריך.
  • תהליכי OAuth 2.0 משתמשים ב-refresh_token כדי לקרוא לנקודת הקצה של אסימון Google OAuth2 ולקבל אסימון גישה חדש למשך שעה אחת.

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

משתמשים ותפקידים

שאלות נפוצות לגבי משתמשים ותפקידים:

האם חשבון האימייל של המפתח צריך להיות קיים כבר ב-Merchant Center?

לא. אם כתובת האימייל שמשמשת להרשמה לא קיימת כבר ב-Merchant Center,‏ Merchant API יוצר את החשבון ב-Merchant Center עם כתובת האימייל שצוינה, כשהסטטוס שלו הוא 'בהמתנה'. אם כתובת האימייל של המפתח שייכת למשתמש קיים בחשבון Merchant Center, הוא מקבל אוטומטית את התפקיד API developer.

האם כתובת האימייל של איש הקשר של המפתח צריכה להיות עם הרשאות אדמין ב-Merchant Center?

לא. המשתמש ב-Merchant Center שמשויך לכתובת האימייל של איש הקשר של המפתח מקבל כברירת מחדל את התפקיד API developer שנדרש כדי לקבל התראות חשובות. עם זאת, יש לו הרשאות מינימליות ב-Merchant Center. כדי לאפשר למשתמש הזה לבצע קריאות נוספות ל-API או לנהל הגדרות בממשק המשתמש של Merchant Center, צריך להקצות לו תפקידים נוספים, כמו STANDARD או ADMIN. מידע נוסף על התפקידים ב-Merchant Center זמין במאמר על סוגי גישה.

אילו הרשאות יש לתפקיד 'API developer'?

תפקיד API developer הוא תפקיד עם הרשאות מינימליות ב-Merchant Center. אם אתם מתכננים להשתמש בכתובת האימייל של איש הקשר למפתחים כדי לאשר קריאות ל-Merchant API, מומלץ להוסיף הרשאות ADMIN או STANDARD כדי לאפשר למשתמש לבצע קריאות ל-API.

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

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

איך משנים את כתובת האימייל ליצירת קשר של המפתח אחרי הרישום הראשוני?

כדי לנהל או לשנות אנשי קשר, אפשר להשתמש בשירות הרגיל accounts.users או בדף 'גישה ושירותים' בממשק המשתמש של Merchant Center כדי להוסיף או להסיר משתמשים עם התפקיד API developer.

מה קורה אם מסירים מחשבון Merchant Center את המשתמש האחרון עם הרשאת API developer?

כדי למנוע שיבושים מיידיים בשירות, מופעלת תקופת חסד של 30 יום. בזמן הזה:

  • האדמינים יקבלו שלושה אימיילים עם הודעות חובה על השירות (בדרך כלל כ-30, 17 ו-4 ימים לפני החסימה).
  • הקריאות ל-API ימשיכו לפעול כרגיל.
  • אם לא תוסיפו API developer חדש לפני שתקופת החסד תסתיים, קריאות ל-API מפרויקטים משויכים ב-Google Cloud ייחסמו עם שגיאה AUTH_GCP_NOT_REGISTERED.

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

מה קורה אם מוחקים את מספר חשבון Merchant Center שאליו נרשם חשבון הפיתוח?

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

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

למה אני לא רואה את התפקיד 'API developer' ב-Merchant Center?

התפקיד API developer מוצג בממשק המשתמש של Merchant Center רק אחרי שמבצעים את רישום המפתחים בחשבון Merchant Center הרלוונטי. חשבונות Merchant Center שלא נרשמו לא רואים את התפקיד API developer.

תרחישים מיוחדים לדוגמה

שאלות נפוצות על תרחישי שימוש מיוחדים:

אני סוכנות או מפתח צד שלישי שמנהל כמה חשבונות של מוֹכרים. מה הדרך הכי טובה להגדיר את זה?

מפתחים וסוכנויות של צד שלישי צריכים להחזיק בחשבון Merchant Center ראשי משלהם ולרשום את כל הפרויקטים שלהם ב-Google Cloud בחשבון המרכזי הזה. אל תרשמו את הפרויקט שלכם ב-Google Cloud בחשבון של כל מוֹכר בנפרד.

איך מתבצע רישום ב-Google App Scripts?

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

האם אפשר לבדוק אם מזהה Merchant Center רשום למזהה פרויקט ספציפי ב-Google Cloud?

כן. אפשר לבדוק איזה מספר חשבון Merchant Center רשום לפרויקט בענן ספציפי ב-Google Cloud באמצעות method‏ getAccountForGcpRegistration. כדי להסיר קישור של פרויקט ב-Google Cloud לחשבון Merchant Center, משתמשים בשיטה unregisterGcp.

מעבר מ-Content API ל-Merchant API למשתמשי אפליקציית Google & YouTube ב-Shopify

שאלות נפוצות לגבי מעבר מ-Content API ל-Merchant API בפלטפורמות ובאפליקציות של צד שלישי:

האם צריך לעשות משהו כדי לעבור מ-Content API ל-Merchant API?

אין צורך בפעולה נוספת. אם אתם משתמשים באפליקציית Google ו-YouTube ב-Shopify כדי לנהל את הפידים שלכם ב-Merchant Center, ‏Google תטפל בהעברה מ-Content API ל-Merchant API.

האם המעבר ישנה את מזהי המוצרים שלי?

לא, המעבר לא משנה את מזהי המוצרים בפידים שלכם ב-Merchant Center.

האם צריך להתקין מחדש את אפליקציית Google & YouTube ב-Shopify כדי להשלים את המעבר?

לא נדרשת פעולה מצידכם כדי להשלים את המעבר. אין צורך להתקין מחדש את אפליקציית Google & YouTube.

למה אני עדיין רואה מקורות נתונים של Content API ב-Merchant Center?

יכול להיות שמקורות נתונים של Content API עדיין יופיעו ב-Merchant Center במהלך המעבר ל-Merchant API. מקרים כאלה הם צפויים ולא נדרשת פעולה מצידכם.