שאלות נפוצות

בקטע הזה מפורטות שאלות נפוצות בנושא הרשמה כמפתח ב-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 Cloud עבור כתובת האימייל
  • מוודאים שכתובת האימייל שדרכה נותנים הרשאה קיימת בחשבון 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 Auth שמטפלות ברוטציה הזו באופן אוטומטי, כך שהאפליקציה שלכם אף פעם לא תהיה מושבתת.

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

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

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

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

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

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

כדי למנוע שיבושים מיידיים בשירות, מופעלת תקופת חסד של 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 Apps Script?

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

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

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