חשוב להשתמש במפתח הזיהוי שנלקח מרב מסר בשדה של user_token.
כאשר תישלח קריאת הזדהות כזו, השרתים שלנו יחזירו תגובה אובייקט JSON המכיל את ה-
access_token. בכל בקשה עתידית שתשלח ל-API (למשל, יצירת נמען חדש), יהיה עליך לצרף טוקן זה לכותרות הבקשה (Headers) תחת המפתח
Authorization בתצורת
Bearer access_token.
תרחישי שימוש ושילוב עם מערכות חיצוניות (Use Cases)לאחר ביצוע תהליך ההזדהות המוצלח וקבלת ה-Access Token, ה-API פותח דלת למגוון רחב של אינטגרציות ואוטומציות ללא מגע יד אדם. להלן מספר דוגמאות מרכזיות לאופן שבו ניתן להשתמש בממשק:
1.
סנכרון נתונים אוטומטי מול מערכות ניהול לקוחות (CRM).ארגונים רבים מנהלים את תהליכי המכירה שלהם במערכות CRM חיצוניות. חיבור דרך ה-API מאפשר סנכרון דו-כיווני בזמן אמת:
התרחיש: כאשר איש מכירות מזין ליד חדש ל-CRM, או מעדכן סטטוס של לקוח קיים (למשל, מ"מתעניין" ל"לקוח משלם").
הפעולה ב-API: המערכת החיצונית שולחת קריאה ל-API של רב מסר כדי להוסיף את הנמען לרשימת תפוצה ייעודית (למשל "לקוחות פעילים"),
להסיר אותו מרשימת ה"מתעניינים", ולעדכן שדות מותאמים אישית (Custom Fields) כמו תאריך רכישה אחרון או איש הקשר המטפל.
2.
טריגרים ואוטומציות מבוססות מסחר אלקטרוני (E-commerce)
אתרי סחר יכולים להשתמש ב-API כדי לשפר את אחוזי ההמרה וליצור מסעות לקוח חכמים:
התרחיש: לקוח מוסיף מוצרים לעגלת הקניות באתר אך נוטש לפני ביצוע התשלום, או לחלופין מסיים רכישה בהצלחה.
הפעולה ב-API: אתר הסחר מעביר קריאה לרב מסר להוספת
תגית (Tag) ספציפית לאותו נמען (כגון: "נטש-עגלה" או "רכש-קורס-דיגיטלי").
הוספת התגית דרך ה-API יכולה להפעיל באופן מיידי סדרת דיוורים אוטומטית שהוגדרה מראש ברב מסר כדי לעודד את הלקוח להשלים את הרכישה.
3.
ניהול הרשמות מאירועים או פלטפורמות וובינר
כאשר שיווק האירועים מתבצע במערכות סגורות שלא תמיד מציעות חיבור מובנה:
התרחיש: משתמש נרשם להדרכה אינטרנטית (וובינר) דרך מערכת חיצונית או ממלא טופס בדף נחיתה עצמאי (למשל דרך שירותי ענן או אפליקציות צד שלישי).
הפעולה ב-API: ברגע ההרשמה, פלטפורמת האירועים משדרת את פרטי הנרשם ל-API של רב מסר. הנמען נוצר במערכת ומשויך מידית לרשימת הדיוור של האירוע, כך שיתחיל לקבל אוטומטית תזכורות וקישורי התחברות לפני מועד השידור.
4.
שילוב בפלטפורמות ענן ואוטומציה ללא קוד (No-Code/Low-Code)
מנהלי מערכות ואנשי QA המשתמשים בכלים כמו Make או Zapier, יכולים לבנות תהליכים מורכבים (Workflows) באמצעות מודולים של בקשות רשת (HTTP Requests):
התרחיש: הצורך להעביר מידע בין מספר מערכות במקביל, המבוסס על חוקיות לוגית עסקית (למשל: סינון נמענים לפי תחומי עניין לפני הכנסתם לרב מסר).
הפעולה ב-API: באמצעות הגדרת מפתחות ההזדהות (client_id, client_secret ו-user_token) במודול ה-HTTP פעם אחת, ניתן לבנות "תרחיש" ויזואלי המבצע פניות ל-API של רב מסר כדי לשלוף נתונים , לעבד אותם, ולהעבירם למערכות אנליטיקה או ללוחות בקרה פנימיים של הארגון.
דגשים חשובים לפיתוח ותחזוקה
אבטחת מידע: הקפד לשמור את ה-client_secret ואת ה-user_token בסביבה מאובטחת (למשל כמשתני סביבה - Environment Variables) ולא בקוד חשוף (Hardcoded). ובכל מקרה לא לשתף את המפתחות הללו עם גורמים שאתם לא רוצים שתהיה להם גישה חופשית לחשבון שלכם ברב מסר.
תוקף הטוקן: שים לב כי ה-access_token שמתקבל הוא בעל תוקף זמני. בתכנון המערכת החיצונית שלך, מומלץ להטמיע מנגנון שיודע לזהות שגיאות מסוג 401 Unauthorized, ולבצע בקשת הזדהות מחדש (Refresh) באופן אוטומטי.
מבנה נתונים: ודא כי כל בקשות ה-POST או ה-PUT שאתה שולח ל-API מוגדרות עם ה-Header של Content-Type: application/json