Recherche et résolution

Les deux endpoints répondent à des moments différents du cycle de vie.

Lors d’une sélection utilisateur

1. L’interface envoie la saisie à votre backend.
2. Votre backend appelle GET /v1/interests/search.
3. L’utilisateur choisit un résultat.
4. Votre backend persiste son UUID, son libellé et sa catégorie.

La recherche renvoie un top-N non paginé. Quand l’interface limite la recherche à plusieurs catégories, répétez category dans une seule requête au lieu de lancer un appel par catégorie : Orbit n’authentifie et ne décompte alors qu’une requête. Son classement peut évoluer : ne stockez jamais une position de résultat ou le texte saisi comme identité.

Lors de la maintenance

Regroupez les UUID utiles et appelez POST /v1/interests/resolve par lots de 100 au maximum. Un traitement périodique, une lecture métier importante ou une opération de synchronisation sont de bons moments pour résoudre les références. Il est rarement nécessaire de le faire à chaque rendu d’écran.

Architecture

Application publique
       │
       ▼
Backend du produit ── secret Orbit ──► Orbit API
       │
       ▼
UUID + instantané du libellé et de la catégorie

Consultez le guide Stocker et maintenir les UUID Orbit pour un exemple de table consommatrice.