Utiliser l'API Lookup dans DQE One Standalone

Une fois que vous avez indexé des enregistrements avec un process Index Records (voir Create and launch a process in DQE One Standalone), vos propres applications peuvent interroger cet index en temps réel via une petite API REST — pour alimenter une recherche en saisie progressive, ou pour vérifier l'existence d'un doublon avant de créer un nouvel enregistrement.

Authentification

Les 4 endpoints ci-dessous utilisent les mêmes identifiants que le serveur MCP et le reste de l'API REST de DQE One Standalone : HTTP Basic Auth avec votre email de compte et votre jeton API.

# Linux / macOS
echo -n "you@example.com:your_api_token" | base64

# Windows PowerShell
[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("you@example.com:your_api_token"))

Trouvez ou régénérez votre jeton sous My Account > API Token. Envoyez-le sous la forme Authorization: Basic <valeur base64> sur chaque requête.

Utilisez les identifiants d'un compte réel et existant — un en-tête bien formé mais référençant un email inexistant renvoie actuellement une erreur serveur plutôt qu'une réponse "non autorisé" propre.

Ces endpoints autorisent aussi les requêtes cross-origin : vous pouvez donc les appeler directement depuis un navigateur (par exemple pour construire un champ de recherche en temps réel). Si vous le faites, gardez à l'esprit que votre jeton API serait alors visible par quiconque inspecte la page — pour tout usage au-delà d'un outil interne de confiance, appelez plutôt ces endpoints depuis votre propre backend et gardez le jeton côté serveur.

Quel endpoint utiliser

GET /api/searchGolden existe aussi et prend les mêmes paramètres que searchRecords — mais il exécute actuellement exactement la même recherche littérale/phonétique, pas une recherche de matching de doublon. Malgré son nom, il ne renvoie pas d'enregistrement golden et n'applique aucune règle de matching. Utilisez lookupGolden pour cela.

Identifier quel index interroger

Chaque endpoint a besoin de savoir quelles données de process Index Records interroger. Fournissez l'un des deux :

• pid — l'id du process Index Records.
• recordType — le nom de l'objet/table qu'il indexe (par ex. un nom d'objet Salesforce ou Dynamics). Standalone résout cela vers le process Index Records publié, non archivé, le plus récemment créé qui indexe cet objet — si aucun ne correspond, vous obtenez une erreur plutôt qu'un repli silencieux sur autre chose.

Si aucun des deux n'est fourni, la requête échoue avec {"status":"error","error":"Either 'pid' or 'recordType' must be provided"}.

GET /api/searchRecords

Paramètres (chaîne de requête) :

Renvoie un tableau JSON d'enregistrements correspondants — chacun est l'ensemble complet des champs stockés au moment de l'indexation, plafonné à 50 résultats (pas de pagination). Il n'y a pas de score de distance : un enregistrement correspond à l'un des paliers de recherche ci-dessous, ou ne correspond pas du tout.

Standalone essaie chaque palier dans l'ordre et s'arrête dès que l'un d'eux renvoie suffisamment de résultats :

1. Une correspondance exacte sur un mot entier.
2. Une correspondance partielle/par préfixe (utile pendant que la personne tape encore).
3. Une correspondance phonétique en français.
4. Une correspondance phonétique générique.

En pratique, cela signifie qu'un terme de recherche court ou légèrement mal orthographié peut quand même faire remonter le bon enregistrement — mais cela signifie aussi qu'une recherche peut occasionnellement renvoyer un enregistrement phonétiquement proche qui n'est pas celui visé (par ex. rechercher "Dupont" peut aussi faire remonter "Dupond").

Exemple :

curl -G "https://your-standalone-url/api/searchRecords" \
  --data-urlencode "search=Dupont" \
  --data-urlencode "recordType=Contact" \
  -H "Authorization: Basic <valeur base64>"

POST /api/lookupRecords

Corps : un objet JSON de paires champ/valeur sur lesquelles matcher, plus pid ou recordType (dans le corps ou en paramètres de requête), par exemple :

{
  "pid": 12,
  "LastName": "Dupont",
  "Email": "a@b.com"
}

Exemple :

curl -X POST "https://your-standalone-url/api/lookupRecords" \
  -H "Authorization: Basic <valeur base64>" \
  -H "Content-Type: application/json" \
  -d '{"recordType": "Contact", "LastName": "Dupont", "Email": "a@b.com"}'

Renvoie un tableau JSON de tous les enregistrements candidats que les règles de matching de votre RuleSet considèrent comme une correspondance possible — pas de limite sur le nombre de résultats et pas de classement/score par enregistrement. Considérez cela comme une liste à affiner vous-même, pas comme une réponse définitive.

POST /api/lookupGolden — vérification de doublon en temps réel

Même corps de requête que lookupRecords. C'est le seul endpoint qui applique un scoring complet — il réutilise les mêmes algorithmes de matching et les réglages de Threshold configurés dans l'onglet Matching de votre RuleSet.

curl -X POST "https://your-standalone-url/api/lookupGolden" \
  -H "Authorization: Basic <valeur base64>" \
  -H "Content-Type: application/json" \
  -d '{"recordType": "Contact", "LastName": "Dupont", "Email": "a@b.com"}'

Réponse, si une correspondance est trouvée :

{
  "certainty": 0.92,
  "matched_by": "Name + Email",
  "record": { "LastName": "Dupont", "Email": "a@b.com", ... }
}

• certainty — un score de 0 à 1 (1 = correspondance exacte), dérivé du score de distance de la règle de matching.
• matched_by — le nom de la règle de matching ayant produit le meilleur score.
• record — l'enregistrement indexé complet. Si votre process Index Records a un champ Parent Id configuré, il s'agit du parent de l'enregistrement correspondant plutôt que de la correspondance elle-même.

Si rien ne correspond suffisamment pour satisfaire le Threshold d'une règle, la réponse est un objet vide {} — à traiter comme "aucun doublon trouvé".

Maintenir l'index à jour

Il n'y a pas d'indexation incrémentale — à chaque exécution du process Index Records, il reconstruit entièrement son index depuis zéro. Pour garder des résultats à jour :

• Relancez le process manuellement, ou planifiez-le (voir Schedule a process in DQE One Standalone) — la fréquence minimale disponible est toutes les 15 minutes.
• Modifier les règles de matching du RuleSet prend effet immédiatement sur ces 4 endpoints sans qu'il soit nécessaire de relancer quoi que ce soit — mais cela n'affecte que la façon dont les requêtes futures sont scorées, pas les données indexées elles-mêmes.

Gestion des erreurs

Presque toutes les erreurs — un pid/recordType manquant, un recordType inconnu, un corps de requête mal formé — reviennent sous forme d'une réponse HTTP 200 normale avec {"status":"error","error":"..."} dans le corps. Le seul cas qui renvoie un statut HTTP différent est l'échec d'authentification (401). Vérifiez toujours le corps de la réponse, pas seulement le code HTTP.

Limites

• searchRecords/searchGolden renvoient au maximum 50 résultats, sans pagination — affinez votre terme de recherche si vous avez besoin d'en voir plus.
• Il n'y a pas de limitation de débit intégrée sur ces 4 endpoints. Si vous les appelez depuis une intégration à fort trafic (par exemple un champ de recherche public), ajoutez votre propre limitation de votre côté plutôt que de compter sur DQE One Standalone pour se protéger lui-même.

Articles liés

• Field Reference in DQE One Standalone
• Create and launch a process in DQE One Standalone
• Connect a data source in DQE One Standalone
• Configure a RuleSet in DQE One Standalone
• Schedule a process in DQE One Standalone