Contrat API — Campagnes marketing (déclaration & désabonnement)
Base : https://live.jmoai.net/api/v1/marketing. Authentification : JWT client.
Deux routes seulement sont ouvertes à l’application. Tout le reste — calendrier, activation, diffusion — vit dans le périmètre admin et n’est pas exposé au client.
⚠️ L’identité vient du jeton, jamais du corps de la requête. Un manager_id envoyé par le
client est ignoré : sans cela, n’importe qui pourrait basculer n’importe quel compte dans une
séquence commerciale.
Pourquoi ces routes existent
La campagne « Starlink Anti-Restriction » se joue en deux temps : un discours de prévention pour l’opérateur qui n’est pas encore touché par la politique d’usage de son fournisseur, un discours de remédiation pour celui qui l’est déjà.
Rien dans le backend ne dit qui est restreint. Aucune détection n’est enregistrée, et deviner produirait un message qui parle à côté. C’est donc le client qui déclare sa situation, et cette déclaration seule ouvre la séquence de remédiation. Sans déclaration, un client est traité en prévention — l’hypothèse prudente.
POST /campagnes/{code}/piste
Déclare la situation du gérant authentifié pour une campagne.
POST /api/v1/marketing/campagnes/STARLINK_ANTI_RESTRICTION_7J/piste
Authorization: Bearer <jwt client>
Content-Type: application/json
{ "piste": "RESTREINT" }
| Champ | Valeurs | Sens |
|---|---|---|
piste |
PREVENTION | RESTREINT |
RESTREINT = le lien du gérant est déjà bridé par son fournisseur |
Réponse 200 :
{ "success": true, "data": { "manager_id": "client_…", "piste": "RESTREINT" } }
Erreurs : CAMPAGNE_PISTE_INVALIDE (400) si la valeur n’est ni PREVENTION ni RESTREINT,
CAMPAGNE_INCONNUE (400) si le code de campagne n’existe pas.
La déclaration est idempotente : la rejouer met simplement la valeur à jour. Un gérant peut
donc passer de PREVENTION à RESTREINT en cours de campagne, et il recevra la séquence de
remédiation à partir de la touche suivante.
Ce que l’écran doit faire
Le courriel et les notifications du jour 1 pointent vers jmoai.net/client/starlink. L’écran
doit poser une seule question — « votre débit est-il déjà bridé par votre fournisseur ? » —
et appeler cette route avec la réponse. C’est le seul geste attendu de l’utilisateur.
POST /desabonnement
Retire le gérant authentifié de toutes les campagnes, ou d’un canal.
POST /api/v1/marketing/desabonnement
Authorization: Bearer <jwt client>
Content-Type: application/json
{ "canal": "EMAIL", "motif": "trop de messages" }
| Champ | Valeurs | Défaut |
|---|---|---|
canal |
TOUS | PUSH | EMAIL |
TOUS |
motif |
texte libre, facultatif | null |
Réponse 200 : { "success": true, "data": { "desabonne": true, "manager_id": "…", "canal": "EMAIL" } }
Le désabonnement ne touche que le marketing. Les courriels transactionnels — licence, retrait, paiement, alerte d’expiration — continuent d’être envoyés : ce ne sont pas des sollicitations commerciales, et les couper priverait le client d’informations qu’il a payées.
⚠️ Cette route doit être atteignable depuis l’application. Sans elle, une séquence de plusieurs jours transforme des clients en signalements « indésirable », et c’est la réputation du domaine expéditeur qui se dégrade — donc aussi la délivrabilité des courriels de licence.