Widget B2B — historique sur d'autres appareils

Cette section couvre la restauration de l'historique personnel du widget lorsque la même personne ouvre le site depuis un autre navigateur ou appareil.

Le site doit authentifier la personne. Son backend obtient et conserve en privé le credential de restauration pour cet utilisateur et ce widget. Le navigateur la passe à init() avec le profil.

Pour le script seul, ou pour préremplir le profil et l'entreprise en restant en session invité, voir Widget B2C. Points d'accès, persistance et concurrence de restore_id : Intégration technique.

Ce que cela ajoute par rapport à la session invité

	Invité	Restauration
Connexion sur le site	Non requise	Requise, parce que le credential sort de votre backend
Données qui identifient la conversation	Credential invité du navigateur, ou profil passé à `init()`	`external_user_id` et `restore_id` ensemble
Continuité	Même navigateur	Navigateurs et appareils différents, sur le canal widget autorisé
Qui émet le credential	Loader	Backend du site, via Quoting24

name, phone, email, external_id, company_name et external_user_id, seuls, ne restaurent pas l'historique. external_user_id sans restore_id ne suffit pas. Le champ est restore_id, en snake case : restoreId n'est pas un champ du loader.

La restauration ne fusionne pas d'anciennes sessions invité et ne partage pas l'historique entre collègues de la même entreprise. Elle concerne seulement le canal widget.

Vous pouvez envoyer les champs entreprise dans le même init(). L'association ou la création suit les règles du payload invité : elle est indépendante de la restauration et ne prouve pas l'identité.

Flux

Le client se connecte sur le portail
Le backend authentifié demande un credential à Quoting24 (provisionRestoreId) ou réutilise celui déjà enregistré
La page appelle init() avec le même external_user_id, le restore_id et, s'ils servent, les données d'entreprise
Quoting24 vérifie le credential et montre les conversations du widget visibles pour cette personne, y compris celles déjà fermées
À la déconnexion, ou au changement de personne, la page appelle reset() pour que la conversation précédente ne reste pas dans le navigateur

widget.init({
  external_id: "52",
  company_name: "Ricambi Stella S.r.l.",
  name: "Mario Rossi",
  phone: "+393331234567",
  email: "mario.rossi@ricambi-stella.example",
  external_user_id: "1042",
  restore_id: session.restore_id,
});

restore_id est la réponse du backend pour l'utilisateur authentifié. Utilisez-la sans la modifier. Maximum 200 caractères. Elle exige l'external_user_id correspondant : ID stable de la personne, non vide, maximum 100 caractères après trim. Ce n'est pas un ID d'entreprise partagé.

external_id est comparé à web_code. Avec company_name, il peut créer l'entreprise manquante. Il n'authentifie pas l'utilisateur et ne remplace pas restore_id.

Prérequis

En plus du branding, des domaines et du code d'intégration :

intégration backend autorisée dans Quoting24
secret privé de l'intégration, uniquement sur le serveur
point d'accès de provisioning, en général widget.provisionRestoreId
stockage privé dans la base du site, un credential par utilisateur et widget

La clé publique dans l'URL du script et le secret d'intégration sont des valeurs différentes. Voir Vue d'ensemble.

Point d'accès sur le backend du site

/api/widget/session est un exemple à implémenter dans le portail. Ce n'est pas une URL publique de Quoting24.

POST /api/widget/session
Content-Type: application/json

{}

{
  "external_user_id": "1042",
  "external_id": "52",
  "company_name": "Ricambi Stella S.r.l.",
  "name": "Mario Rossi",
  "phone": "+393331234567",
  "email": "mario.rossi@ricambi-stella.example",
  "restore_id": "<credential-renvoye-par-quoting24>"
}

L'identité se déduit de la session serveur, pas d'un ID choisi par le navigateur
Cache-Control: no-store
Ne journalisez pas et ne mettez pas en cache restore_id
Ne mettez pas de secrets dans l'URL du script ni dans des attributs data-*
Enregistrez le credential avant de la renvoyer au navigateur

Le contrat vers Quoting24 (attempt_id, saved_restore_id, verrou, réutilisation de la clé) est dans Intégration technique.

Si le portail a déjà un point d'accès authentifié qui, pour l'utilisateur courant, renvoie le restore_id de ce widget, utilisez cette réponse. Combinez-la avec l'ID de la personne et la référence d'entreprise dans l'appel à init().

Connexion, rechargement, changement de compte, déconnexion

Distinguez un rechargement de page d'un vrai changement de personne ou de compte.

Rechargement avec la même connexion encore active : init() sans reset(), pour conserver la session invité enregistrée si vous ne faites que redonner le profil. Avec la restauration, réutilisez le credential déjà persisté : n'en générez pas un nouveau à chaque page view
Changement de personne, changement de compte, déconnexion : reset() tout de suite, puis le nouveau profil, ou aucun init() si l'utilisateur est sorti
Écartez les réponses de restauration arrivées après le changement : une ancienne réponse ne doit pas être traitée comme une nouvelle connexion
Dans une SPA, gardez une seule instance dans la structure principale. Un changement de route ne relance pas le provisioning

Si la restauration n'est pas disponible, vous pouvez proposer la conversation invité : reset(), puis init() sans restore_id. Cette conversation reste séparée de l'historique restauré.

Un credential non valide, appartenant à un autre utilisateur ou révoqué est refusé. Quoting24 ne le convertit pas en session invité. Le bouton « Riprova » du widget ne demande pas tout seul un nouveau restore_id à votre backend. L'interface actuelle est en italien, donc ce libellé est en italien.

Exemple de applyWidgetAuth et démontage : Intégration technique.

reset() oublie la session invité de cette instance et le credential enregistré dans le navigateur. Il ne révoque pas restore_id sur le serveur et ne ferme pas les sessions sur les autres appareils. Le site doit mettre à jour les autres onglets ouverts.

Conversations précédentes

Dans l'historique restauré, les conversations déjà fermées peuvent apparaître comme conversation précédente.

Les ouvrir en consultation ne rouvre pas l'ancienne conversation
Les nouveaux messages restent sur la conversation active

Liste de contrôle avant mise en production

[ ] Secret d'intégration uniquement sur le serveur
[ ] external_user_id stable et par personne, identique entre le provisioning et init()
[ ] restore_id persisté avant la réponse au navigateur, et réutilisé aux visites suivantes
[ ] Même utilisateur sur un second navigateur : même historique
[ ] Deux utilisateurs de la même entreprise : historiques distincts
[ ] external_id et company_name vérifiés dans le fichier, sans attendre qu'ils restaurent la conversation
[ ] Déconnexion ou changement de compte pendant le fetch : aucune conversation de l'ancien utilisateur à l'écran
[ ] Passage invité ↔ restauration avec reset() au milieu
[ ] Credential révoqué ou non valide : erreur, sans repli silencieux vers l'invité

Tests et symptômes : Vérifier l'intégration · Résolution des problèmes.