Intégration DiddiSupport

DiddiSupport peut lire un contexte limité d'une commande Food pour traiter un dossier. DiddiFood reste propriétaire de la commande, du paiement local, des montants et de la projection de livraison. Cette route ne déclenche aucune action métier.

Un agent Support autorisé peut approuver ou rejeter une demande de remboursement via le circuit Backoffice audité (food:payments:write). Le client S2S de contexte ci-dessous reste strictement en lecture seule ; il ne reçoit pas de droit de mutation sur les commandes ou les paiements.

Route

GET /internal/v1/support/order/{order_id}/context
Authorization: Bearer <JWT service>
X-Client-ID: <client DiddiSupport provisionné>
X-Support-Context-Scope: diddifood:support-context:read
X-Request-ID: <identifiant de corrélation>

Le JWT doit porter :

service=diddisupport
aud=diddifood
scope=diddifood:support-context:read

Réponse

La réponse suit diddi.context.v1 et contient seulement l'état nécessaire au support : statut de commande, montant total en XOF, statut/méthode de paiement, restaurant, état de livraison et dates de transition. Les identifiants de livraison Food/Send sont présents pour permettre la corrélation interservices.

Les données client, adresse, téléphone, identifiant d'intention DiddiPay et référence commerciale sont masqués et déclarés dans redacted_fields.

Configuration Food

DIDDISUPPORT_CLIENT_ID=diddisupport-staging-diddifood
DIDDISUPPORT_SERVICE_AUDIENCE=diddifood

Le secret ou la clé privée de DiddiFreeID reste dans le service qui demande le JWT. Food ne reçoit aucun secret DiddiSupport.

Erreurs

• 404 RESOURCE_NOT_FOUND : commande inconnue ;
• 401 SERVICE_AUTH_INVALID : JWT ou identifiant manquant ;
• 403 SERVICE_FORBIDDEN ou SUPPORT_CONTEXT_SCOPE_FORBIDDEN : service, client ou scope non autorisé ;
• 503 SERVICE_NOT_CONFIGURED : le client DiddiSupport n'est pas configuré côté Food.