מדריך לשילוב של API עם פלטפורמת צ'אט

המדריך הזה מסביר איך ליצור שילוב של צ'אט בצד השרת באמצעות Apps API. בסיום, השילוב יוכל:

• מאמתים את Apps API.

• ליצור או לעדכן משתמש קצה.

• להתחיל צ'אט עם משתמש הקצה.

• לקבל ולאמת אירועי webhook מ-Contact Center AI Platform.

• לשלוח הודעות SMS בצ'אט.

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

• לסיים את הצ'אט כשהשיחה מסתיימת.

המדריך הזה מיועד למפתחים שיוצרים שירות לקצה העורפי שמחבר בין ממשק צ'אט בבעלות הלקוח לבין פלטפורמת CCAI. ההנחה היא שאתם יכולים ליצור פרטי כניסה ל-API בפלטפורמת CCAI, לארח נקודת קצה (endpoint) של תגובה לפעולה מאתר אחר (webhook) ב-HTTPS, לאחסן סודות באופן מאובטח ולשלוח בקשות HTTP מהשרת שלכם.

המדריך הזה משלים את נקודות הקצה (endpoints) של Apps API Chat. השתמשו במאמרי העזרה של ה-API כדי לקבל את הסכימה המלאה של הבקשות וסכֵימת התשובה, ובמדריך הזה כדי לקבל את תהליך ההטמעה המומלץ מקצה לקצה.

הסברים על המונחים

ההגדרות הבאות רלוונטיות למסמך הזה:

• לקוח: הלקוח של פלטפורמת CCAI שמטמיע את שילוב הצ'אט בתוכנה שלו.

• צרכן: האפליקציה בצד השרת שבבעלות הלקוח, ששולחת בקשות ל-Apps API ומקבלת אירועי webhook של פלטפורמת CCAI.

• משתמש קצה: האדם שמשתמש בתוכנה של הלקוח כדי להתחיל או להמשיך צ'אט עם נציג או נציג וירטואלי.

• ‫Chat: משאב השיחה של פלטפורמת CCAI שנוצר על ידי Apps API.

• נקודת קצה (endpoint) של Webhook: נקודת הקצה של HTTPS באפליקציית הצרכן שמקבלת אירועי צ'אט מפלטפורמת CCAI.

לפני שמתחילים

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

• פרטי הכניסה ל-Apps API

  • יוצרים פרטי כניסה ל-API ב-CCAI Platform דרך Settings‏ > Developer Settings‏ > API Credentials.

  • שומרים את הסוד של פרטי הכניסה בצורה מאובטחת. אל תחשפו אותו בקוד של הדפדפן או של אפליקציית הלקוח לנייד.

• פרטי כתובת ה-URL של הדייר (tenant)

  • מזהים את תת-הדומיין והדומיין של CCAI Platform.

  • כתובת ה-URL הבסיסית של Apps API היא: https://YOUR_SUBDOMAIN.YOUR_DOMAIN/apps/api/v1

• נקודת הקצה של ה-webhook

  • לארח נקודת קצה ציבורית ב-HTTPS שיכולה לקבל בקשות POST מ-CCAI Platform.

  • מגדירים את נקודת הקצה בהגדרות למפתחים של פלטפורמת CCAI.

  • יוצרים ושומרים את הסודות הראשיים והמשניים של ה-webhook.

• הגדרת תור או תפריט

  • מזהים את התור או התפריט שאליו נכנסים צ'אטים חדשים.

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

• זהות משתמש הקצה

  • מחליטים באיזה מזהה קבוע המערכת תשתמש לכל משתמש קצה.

  • שומרים את מזהה משתמש הקצה של פלטפורמת CCAI שמוחזר על ידי Apps API.

• טיפול בהגבלת הקצב של יצירת בקשות

  • ב-CCAI Platform יש הגבלת קצב של יצירת בקשות ל-Apps API. הוסיפו לשילוב ניסיונות חוזרים והשהיה, והימנעו משליחת פרצים של בקשות לדייר יחיד.

אימות ואבטחת webhook

השילוב שלכם משתמש בשני נתיבי אימות:

• אימות של Apps API לבקשות מהשרת שלכם אל CCAI Platform.

• אימות חתימה של Webhook לבקשות מ-CCAI Platform לשרת שלכם.

אימות בקשות של Apps API

הבקשות משתמשות באימות בסיסי של HTTP. יוצרים אסימון API ב-CCAI Platform בקטע Settings > Developer Settings > API Credentials, ומעבירים אותו בשדה password (מומלץ). אם הדייר שלכם משתמש בנתיב האימות הקודם, אתם יכולים להעביר את מפתח החברה בתור שם המשתמש ואת הסוד של החברה בתור הסיסמה. במאמרי העזרה של Apps API מוסבר איך מגדירים את האימות המלא. בדוגמה הבאה אפשר לראות איך לאמת בקשת Apps API באמצעות אימות בסיסי:

curl -X GET \
  https://YOUR_SUBDOMAIN.YOUR_DOMAIN/apps/api/v1/chats/{chat_id} \
  -u "YOUR_SUBDOMAIN:YOUR_API_TOKEN" \
  -H "Accept: application/json"

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

אימות בקשות webhook

פלטפורמת CCAI שולחת אירועי צ'אט לנקודת הקצה (endpoint) של ה-webhook. כל בקשת webhook כוללת:

• X-Signature

• X-Signature-Timestamp

הכותרת X-Signature יכולה להכיל חתימה ראשית, חתימה משנית או את שתיהן:

primary=<primary_signature> secondary=<secondary_signature>

כל חתימה היא תקציר HMAC-SHA256 בקידוד Base64. הערך החתום הוא הכותרת של חותמת הזמן, שמחוברת לגוף הבקשה בפורמט JSON גולמי:

X-Signature-Timestamp + raw_request_body

ב-webhook handler:

1. כדאי לקרוא את X-Signature וX-Signature-Timestamp.

2. דוחים את הבקשה אם אחת מהכותרות חסרה.

3. דחיית חותמות זמן לא עדכניות כדי להפחית את הסיכון להפעלה מחדש.

4. קוראים את גוף הבקשה הגולמי לפני ניתוח ה-JSON.

5. מחשבים את החתימה הצפויה באמצעות כל סוד פעיל של ה-webhook.

6. משווים בין החתימה שהתקבלה לבין החתימה הצפויה באמצעות השוואה בזמן קבוע.

7. מאשרים את הבקשה אם יש התאמה לסוד פעיל כלשהו.

הדוגמה הבאה להטמעה ב-Ruby ממחישה איך לאמת חתימות של webhooks ב-UJET:

require "base64"
require "openssl"
require "active_support/security_utils"

def parse_ujet_signature(header)
  header.to_s.split(/\s+/).each_with_object({}) do |part, result|
    key, value = part.split("=", 2)
    result[key] = value if key && value
  end
end

def expected_signature(secret, timestamp, raw_body)
  Base64.strict_encode64(
    OpenSSL::HMAC.digest(
      OpenSSL::Digest.new("sha256"),
      secret,
      "#{timestamp}#{raw_body}"
    )
  )
end

def secure_match?(received, expected)
  return false if received.nil? || expected.nil?
  return false unless received.bytesize == expected.bytesize

  ActiveSupport::SecurityUtils.secure_compare(received, expected)
end

def verify_ujet_webhook!(request, primary_secret:, secondary_secret:)
  signature_header = request.headers["X-Signature"]
  timestamp = request.headers["X-Signature-Timestamp"]

  return false if signature_header.nil? || timestamp.nil?

  # Optional but recommended: reject stale requests.
  return false if (Time.now.utc - Time.at(timestamp.to_i).utc).abs > 5.minutes

  raw_body = request.body.read
  signatures = parse_ujet_signature(signature_header)

  expected = [
    expected_signature(primary_secret, timestamp, raw_body),
    expected_signature(secondary_secret, timestamp, raw_body)
  ].compact

  received = [
    signatures["primary"],
    signatures["secondary"]
  ].compact

  received.any? do |received_signature|
    expected.any? do |expected_signature_value|
      secure_match?(received_signature, expected_signature_value)
    end
  end
end

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

תהליך השילוב

התהליך הבא יוצר משתמש קצה, מתחיל צ'אט, מקבל אירועים של פלטפורמת CCAI, מחליף הודעות ומסיים את הצ'אט.

יוצרים או מעדכנים את משתמש הקצה

המטרה: לוודא שלפלטפורמת CCAI יש רשומת משתמש קצה לפני שיוצרים את הצ'אט.

נקודת קצה (endpoint)

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

POST /apps/api/v1/end_users

דוגמה לבקשה

בדוגמה הבאה מוצג גוף בקשה ליצירה או לעדכון של משתמש קצה:

{
  "identifier": "customer-user-12345",
  "email": "[e-mail]",
  "name": "Customer User",
  "phone": "[phone]"
}

מה אפשר לאחסן

שומרים במערכת את מזהה משתמש הקצה של פלטפורמת CCAI מהתגובה. משתמשים במזהה הזה כשיוצרים צ'אט.

מה קורה אחר כך

• אם משתמש הקצה לא קיים, פלטפורמת CCAI יוצרת רשומה חדשה.

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

יצירת הצ'אט

היעד: להתחיל צ'אט חדש ב-CCAI Platform למשתמש הקצה.

נקודת קצה (endpoint)

כדי להתחיל צ'אט חדש, משתמשים בנקודת הקצה הבאה:

POST /apps/api/v1/chats

דוגמה לבקשה

בדוגמה הבאה מוצג גוף בקשה ליצירת צ'אט:

{
  "chat": {
    "menu_id": 123,
    "end_user_id": 456,
    "lang": "en"
  }
}

הקשר אופציונלי לניתוב לנציג וירטואלי

אם הנציג הווירטואלי לבחירת תור צריך הקשר מהאפליקציה, צריך לכלול מטען ייעודי (payload) של הקשר כשיוצרים את הצ'אט, כמו בדוגמה הבאה:

{
  "chat": {
    "menu_id": 123,
    "end_user_id": 456,
    "lang": "en",
    "context": {
      "value": {
        "customer_tier": "gold",
        "issue_type": "billing"
      }
    }
  }
}

נציג וירטואלי יכול להשתמש בערכים מההקשר הזה כדי להחליט לאיזה תור להעביר את הצ'אט.

מה קורה אחר כך

• ה-Apps API מחזיר את המשאב של הצ'אט.

• פלטפורמת CCAI שולחת אירוע webhook מסוג chat_created לנקודת הקצה (endpoint) שהגדרתם ל-webhook.

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

עיבוד אירועי webhook ב-Chat

המטרה: לשמור על סנכרון בין אפליקציית הצרכן לבין מצב הצ'אט ב-CCAI Platform.

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

• מזהה הצ'אט.

• סוג האירוע.

• חותמת הזמן של האירוע.

• שולח ההודעה, סוג ההודעה ותוכן ההודעה, אם האירוע מכיל הודעה.

• כל נתוני ההעברה או ההסטה כשהאירוע מתאר התנהגות ניתוב.

התנהגות מומלצת

• לפני שמעבדים את האירוע, מאמתים כל חתימה של webhook.

• שומרים מזהי אירועים שעובדו או מפתח אירועים דטרמיניסטי, כדי שניסיונות חוזרים לא ייצרו כפילויות.

• להחזיר תגובת 2xx אחרי קבלת האירוע.

• לעבד השפעות משניות במורד הזרם באופן אסינכרוני, כשאפשר.

מה קורה אחר כך

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

שליחת הודעת טקסט.

המטרה: לשלוח הודעה של משתמש קצה מאפליקציית הצרכן לצ'אט של פלטפורמת CCAI.

נקודת קצה (endpoint)

כדי לשלוח הודעת טקסט לצ'אט, משתמשים בנקודת הקצה הבאה:

POST /apps/api/v1/chats/{chat_id}/message

דוגמה לבקשה

בדוגמה הבאה מוצג גוף בקשה לשליחת הודעת טקסט:

{
  "from_user_id": 456,
  "message": {
    "type": "text",
    "content": "Hello, I need help with my order."
  }
}

מה קורה אחר כך

• פלטפורמת CCAI מקבלת את ההודעה.

• ההודעה מופיעה בשיחה עם הנציג או הנציג הווירטואלי.

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

קבלת הודעות מ-CCAI Platform והצגה שלהן

המטרה: להציג הודעות של נציג או של נציג וירטואלי בצ'אט שבבעלות הלקוח.

כשנקודת הקצה של ה-webhook מקבלת אירוע של הודעה:

1. מאמתים את החתימה של ה-webhook.

2. בודקים אם האירוע חדש.

3. מזהים את הצ'אט לפי מזהה הצ'אט.

4. מזהים את השולח ואת סוג ההודעה.

5. מציגים את ההודעה בממשק המשתמש של הצ'אט שבבעלות הלקוח.

6. לשמור את האירוע כדי שהיסטוריית השיחות לא תאבד אם המשתמש ירענן את הדף או ינסה שוב.

מה קורה אחר כך

בממשק המשתמש של הצ'אט שבבעלות הלקוח, ההודעות שנשלחות על ידי נציגים, נציגים וירטואליים ומשתמשי הקצה מוצגות בסדר הנכון. אם האירועים מגיעים בסדר לא נכון, השתמשו בחותמות הזמן של האירועים ובשכבת ההתמדה (persistence layer) שלכם כדי להתאים את סדר התצוגה.

העברת הטיפול מנציג וירטואלי לנציג אנושי

המטרה: להעביר את הצ'אט מטיפול של נציג וירטואלי לתור של נציג אנושי כשמשתמש הקצה צריך עזרה מנציג.

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

נקודת קצה (endpoint)

כדי להעביר צ'אט מנציג וירטואלי לנציג אנושי, משתמשים בנקודת הקצה הבאה:

POST /apps/api/v1/chats/{chat_id}/escalations

דוגמה לבקשה

בדוגמה הבאה מוצג גוף בקשה להעברת צ'אט לטיפול ברמה גבוהה יותר:

{
  "reason": "by_end_user_ask",
  "force_escalate": false
}

מה קורה אחר כך

• אם התור הרלוונטי זמין, הצ'אט מועבר לטיפול של נציג.

• אם אי אפשר להעביר את הצ'אט לתור, ומוגדרות חלופות להסטה, פלטפורמת CCAI משאירה את הצ'אט אצל הנציג הווירטואלי ושולחת אירוע webhook מסוג escalation_deflected עם החלופות שזמינות למשתמש הקצה. החלופות אף פעם לא מגיעות בתגובה להעברה לרמה גבוהה יותר.

• השילוב שלכם מציג למשתמש הקצה את אפשרויות ההסטה הזמינות.

תיעוד של בחירה בהעברה לטיפול ברמה גבוהה יותר או בהסטה

המטרה: להודיע ל-CCAI Platform באיזו אפשרות להסטת פניות משתמש הקצה בחר.

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

נקודת קצה (endpoint)

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

PATCH /apps/api/v1/chats/{chat_id}/escalations/{escalation_id}

ערכים נתמכים של deflection_channel:

• ‫email — משתמש הקצה בוחר באפשרות של הפניית אימייל.

• virtual_agent — משתמש הקצה בוחר להמשיך עם נציג וירטואלי.

• ‫human_agent – משתמש הקצה בוחר להמשיך להמתין לנציג אנושי. הערך הזה רלוונטי רק להסטות בגלל חריגה מהקיבולת.

דוגמה לבקשה

בדוגמה הבאה מוצג גוף בקשה לתיעוד בחירה בהסטה:

{
  "deflection_channel": "email"
}

צריך לשלוח לנקודת הקצה הזו רק ערך deflection_channel נתמך. ‫external_link הוא לא ערך תקף לנקודת הקצה של עדכון ההעברה לטיפול ברמה גבוהה יותר. כשהמשתמש קצה לוחץ על קישור להפניה חיצונית, הצ'אט מסתיים.

מה קורה אחר כך

פלטפורמת CCAI מתעדת את הבחירה בהעברה לטיפול ברמה גבוהה יותר. הבחירה לא מנתבת את הצ'אט – השילוב שלכם פועל בהתאם לבחירה, למשל על ידי סגירת הצ'אט להסטה לאימייל או שליחת בקשה חדשה להעברה לטיפול ברמה גבוהה יותר עם force_escalate: true לבחירה להמשיך להמתין.

לסיים את הצ'אט

המטרה: לסגור את הצ'אט כשהשיחה מסתיימת.

נקודת קצה (endpoint)

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

PATCH /apps/api/v1/chats/{chat_id}/end

דוגמה לבקשה

בדוגמה הבאה מוצג גוף בקשה לסיום צ'אט:

{
  "ended_by_user_id": 456
}

מה קורה אחר כך

• פלטפורמת CCAI מסיימת את הצ'אט.

• נקודת הקצה של ה-webhook מקבלת את האירוע הסופי של מצב הצ'אט.

• האפליקציה מסמנת את הצ'אט כ"הושלם" ומפסיקה לקבל הודעות חדשות ממשתמשי קצה בצ'אט הזה.

אם הצ'אט מסתיים כי משתמש הקצה בחר באפשרות להפנות את הפנייה, אל תשתמשו בנקודת הקצה הזו במקום לתעד את הבחירה הזו. קודם מתעדים את הבחירה בהעברה לטיפול ברמה גבוהה יותר, או מתעדים אותה וסוגרים את הצ'אט בבקשה אחת באמצעות PATCH /apps/api/v1/chats/{chat_id}, ומספקים את escalation_id ו-deflection_channel לצד הסטטוס. אם צ'אט מסתיים בלי שהבחירה תתועד, הבחירה לא תתועד בהעברה, והיא לא תופיע בדוחות על תוצאות ההסטה.

תהליכים מתקדמים

ההסתעפויות הבאות הן אופציונליות. מטמיעים רק את התהליכים שרלוונטיים לשילוב שלכם.

ייבוא תמליל של שיחה קודמת

התהליך הזה מתאים למקרים שבהם למשתמש הקצה כבר הייתה שיחה במערכת שלכם לפני שיצרתם את הצ'אט ב-CCAI Platform, כמו שיחה עם צ'אט בוט.

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

מאמרי העזרה של Apps API כוללים את הסכימה המדויקת של התמליל.

ניתוב צ'אטים באמצעות נציג וירטואלי לבחירת תור

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

1. יצירת נציג וירטואלי לבחירת תור.

2. מקצים את הנציג הווירטואלי לתור הכניסה.

3. לכלול הקשר כשיוצרים את הצ'אט.

4. מגדירים את הנציג הווירטואלי כך שיבדוק את ההקשר ויעביר את הצ'אט לתור הנכון.

5. אפשרויות לטיפול בהסטה אם התור המוגדר כיעד לא זמין.

שליחת תמונות או סרטונים כקבצים מצורפים

צריך להשתמש בתהליך הזה כשמשתמש הקצה שולח מדיה מממשק המשתמש של הצ'אט שבבעלות הלקוח.

תהליך העבודה עם המדיה כולל ארבעה שלבים.

שלב 1 – בקשה לכתובת URL חתומה מראש להעלאה

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

POST /apps/api/v1/chats/{chat_id}/photos/upload
POST /apps/api/v1/chats/{chat_id}/videos/upload

שלב 2 – מעלים את הקובץ לכתובת ה-URL של האחסון שהוחזרה

כוללים את הקובץ ואת כל השדות שפלטפורמת CCAI מחזירה בתגובה ל-presigned-upload.

שלב 3 – הוספת הקובץ שהועלה לשיחה

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

POST /apps/api/v1/chats/{chat_id}/photos
POST /apps/api/v1/chats/{chat_id}/videos

שומרים את ה-media_id שפלטפורמת CCAI מחזירה. מטענים ייעודיים (payloads) של הודעות צ'אט מתייחסים למדיה לפי מזהה המדיה.

שלב 4 – שליחת המדיה כהודעה

כדי לשלוח הודעת מדיה לצ'אט, משתמשים בנקודת הקצה הבאה:

POST /apps/api/v1/chats/{chat_id}/message

דוגמה לבקשה

בדוגמה הבאה מוצג גוף בקשה לשליחת קובץ מצורף של תמונה:

{
  "from_user_id": 456,
  "message": {
    "type": "photo",
    "content": "Photo of the damaged item",
    "media_id": 789
  }
}

נקודת הקצה מקבלת את type,‏ content ו-media_id כערכים שטוחים. אובייקט בתצוגת עץ שסופק ב-content נמחק וההפניה למדיה אובדת. להודעות וידאו, משתמשים בסוג ההודעה video ובסרטון media_id. ‫media_id הוא אח או אחות של content.

שליחת נתונים בהתאמה אישית במהלך צ'אט

כדי לצרף הקשר שהלקוח הגדיר לצ'אט פעיל, משתמשים בנקודת הקצה הבאה:

POST /apps/api/v1/chats/{chat_id}/custom_data

מאמרי העזרה של ה-API של האפליקציות מגדירים את צורת המטען הייעודי (payload) המדויקת ואת ההתנהגות של המפתח השמור.

עדכון זהות של משתמש קצה במהלך צ'אט

אם הזהות של משתמש הקצה משתנה או מתגלה אחרי שהצ'אט מתחיל, צריך להשתמש בנקודת הקצה הבאה:

POST /apps/api/v1/chats/{chat_id}/end_user

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

איסוף נתונים של דירוג או שביעות רצון (CSAT)

השתמשו בנקודות הקצה הבאות של שביעות רצון ודירוג בצ'אט כשאתם משתמשים באינטגרציה משלכם כדי לאסוף דירוגים אחרי הצ'אט:

GET /apps/api/v1/chats/{chat_id}/csat
GET /apps/api/v1/chats/{chat_id}/rating
PATCH /apps/api/v1/chats/{chat_id}/rating

כדי לראות את כללי הזכאות המדויקים ואת המטענים הייעודיים (payloads) של הדירוגים, עיינו במאמרי העזרה של Apps API.