Tracer et escalader un incident
Un ticket de support exploitable doit permettre de retrouver l'appel sans demander au support de reconstituer tout le contexte.
Identifiants utiles
Selon le service, conservez notamment :
| Identifiant | Utilité |
|---|---|
Request-Id | Corrélation technique d'un appel |
correlationId | Identifiant présent dans certaines réponses d'erreur |
tenantSlug | Tenant concerné |
Organization-Id | Organisation ciblée |
jobRunId | Traitement de provisioning |
legalUnitId | Unité légale |
onboardingRequestId | Demande d'onboarding |
flowId | Flux traité par Flow Service |
trackingId | Corrélation métier côté appelant |
Informations à fournir
Pour faciliter le diagnostic, fournissez :
- environnement : SANDBOX ;
- API : Partner APIs ou Tenant Public API ;
- endpoint et méthode HTTP ;
- date et heure précises avec fuseau ;
- code HTTP ;
- identifiants de corrélation disponibles ;
- tenant / organisation concernée ;
- une description courte de l'action attendue et du résultat observé ;
- le body de requête lorsque cela est nécessaire et qu'il ne contient pas de secret ;
- le body de réponse ou le Problem Details reçu.
Ce qu'il ne faut jamais envoyer
Ne transmettez pas dans un ticket :
client_secret;- access token complet ;
- secret bootstrap ;
- mot de passe ;
- données personnelles inutiles au diagnostic.
Exemple de récapitulatif
Environnement : SANDBOX
API : Tenant Public API / Flow Service
Méthode : POST
Endpoint : /v1/flows/search
Heure : 2026-09-10T10:15:00+02:00
HTTP : 400
Organization : <valeur>
Request-Id : <valeur>
CorrelationId : <valeur si présent>
Attendu :
Recherche des nouveaux flux depuis le dernier point de reprise.
Observé :
La requête est rejetée avant traitement.
Avant l'escalade
Vérifiez le même appel dans le Swagger ou dans la collection Postman correspondante. Cela permet de déterminer rapidement si le problème provient du contrat de requête ou du comportement du service.