שאלות נפוצות

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

רישום כללי

שאלות נפוצות על תהליך הרישום:

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

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

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

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

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

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

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

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

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

השדה של כתובת האימייל ליצירת קשר עם המפתח הוא אופציונלי ב-method‏ registerGcp. אם לא תספקו ערך לשדה הזה בזמן ההרשמה, תצטרכו ליצור משתמש עם התפקיד API developer בממשק המשתמש של Merchant Center או באמצעות קריאה ל-method‏ 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.
• סוכנויות, מפתחים וצדדים שלישיים אחרים: אם אתם עסק של צד שלישי, כמו סוכנות או מפתח צד שלישי, שמנהל כמה חשבונות של מוכרים, ואין לכם מספר חשבון Merchant Center אחד שמייצג את העסק שלכם, אתם צריכים ליצור חשבון Merchant Center ראשי חדש ולבקש להמיר אותו לחשבון מתקדם.

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

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

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

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

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

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

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

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