Remontée des publications vers Trustt

1 État actuel

La réception colis est résolue. La publication reste manuelle.

Objectif : quand un ambassadeur envoie son lien (via le brief Trustt SMS) ou qu'un opérateur l'ajoute à la main, le pousser à Trustt automatiquement, exactement comme le colis.

2 Ce qu'on a côté Trustt SMS

Tout est prêt côté données et plomberie : c'est une copie du dispositif réception.

3 Ce que Trustt expose aujourd'hui

5 endpoints : 4 en lecture, 1 seul en écriture (save_receipt). Les posts sont en lecture seule, et sans l'URL.

realizedUgc.posts[] (sur l'endpoint ambassadors, LECTURE) :
{
  "socialTypeId": 2,
  "postTypeId": 4,
  "postTypeLabel": "Story Instagram",
  "status": "pending",
  "dateCrea": "2026-04-30 21:05:24"
}
// pas d'URL du post

Constat : il n'existe aucun endpoint pour déclarer une publication (équivalent de save_receipt côté post), et les posts lus ne portent pas l'URL.

Relevé exhaustif (crawl live 19/06/2026) : tout le compte

Vérifié en appelant l'API en prod sur l'ensemble du compte (pas seulement nos campagnes liées) : 54 entreprises, 98 marques, 334 campagnes, 9594 ambassadeurs, 4141 posts réels. C'est une certitude empirique, plus une lecture de la doc.

Trustt auto-détecte déjà les posts. Sur tout le compte, des milliers de posts sont valid sans qu'on ait rien poussé. Trustt a donc son propre pipeline de détection. Le modèle d'un post est par type, pas par lien : aucune URL nulle part, sur 4141 posts.

3b Le contenu suivi : 4 briques (attendu vs réalisé)

Relevé du compte entier (335 campagnes pour l'attendu, 9594 ambassadeurs / 4141 posts pour le réalisé). « Publication » au sens large = 4 briques, pas seulement le post.

Volumes attendus vs réalisés

Types de post : attendu étroit, réalisé large

Conséquence remontée : l'attendu formel ne décrit que 2 types (Post Instagram, Vidéo TikTok). Les ambassadeurs publient pourtant Story, Facebook, Youtube, Article, Pinterest. Une remontée pilotée seulement par expectedPost raterait tout ce contenu hors IG/TikTok réellement publié.

Combinaisons de contenu attendu (par campagne)

4 Les deux manques (pas un seul)

Le risque central, confirmé par le relevé live : Trustt auto-détecte déjà les posts et les compte par type, sans URL. Si on pousse une URL pour un post que Trustt a déjà détecté, il ne peut pas dédupliquer (il ne connaît pas les liens) → il comptera deux posts du même type. Donc tant que l'URL n'est pas la clé d'un post côté Trustt, pousser nos publications est dangereux, pas juste impossible à réconcilier. C'est le vrai prérequis, avant même save_post.

Sous-problème : le type de post

On a une URL et une plateforme grossière (instagram). Trustt range par postTypeId fin (Post Instagram = 3 vs Story Instagram = 4, Post Facebook = 5, Vidéo Youtube = 7, Vidéo TikTok = 9). On ne sait pas distinguer un post d'une story Instagram depuis l'URL.

Donc save_post doit accepter l'URL et inférer le type côté Trustt, ou se contenter d'un socialTypeId (plateforme) quand on ne peut pas fournir mieux.

5 Endpoint proposé : save_post à créer

Calé sur le style réel de votre API (un endpoint par signal, comme save_receipt), pas sur un puits d'évènements générique.

POST https://pro.trustt.io/api_trusttsms/save_post
  ?key=xxx
  &cid=<candidateUUID>
  &url=<url du post, encodee>
  &platform=instagram|tiktok|youtube
  &date=2026-06-05%2012:10:00          (Y-m-d H:i:s)
  [&postTypeId=<int>]                 optionnel

Réponse idéale (pour pouvoir réconcilier)

{
  "data": {
    "uuid_candidate": "679c7491-...",
    "postId": "...",            // id du post cree cote Trustt
    "url": "https://...",       // l'URL, pour le rapprochement
    "postTypeId": 9,            // type resolu cote Trustt
    "status": "pending"         // probablement a valider cote Trustt
  }
}

Dédup idempotente sur (cid, url) : rejouer le même save_post (re-push, réconciliation) ne crée pas de doublon. C'est ce qui permet de pousser sans risque.

À terme : un delete_post (symétrique du futur cancel_receipt) pour un post rejeté ou retiré localement. Hors périmètre de la première phase.

6 Questions de politique à trancher

7 Architecture côté Trustt SMS (dès que l'endpoint arrive)

Copie du dispositif réception, en deux phases.

Verdict (revu après relevé live) : bloqué côté Trustt, et le blocage est plus profond qu'un endpoint manquant. Le modèle de post de Trustt est par type, sans URL, et Trustt auto-détecte déjà les posts. Prérequis, dans l'ordre : (1) Trustt traite l'URL comme la clé d'un post (stockage + lecture) pour pouvoir dédupliquer notre push contre sa propre détection ; (2) alors seulement save_post a un sens. Sans (1), pousser nos publications crée des doublons. Côté Trustt SMS, tout est prêt.