Relancer les élèves sans bilan depuis 14 jours

Chaque lundi, les élèves sans bilan depuis 14 jours reçoivent un court message dans l'app. Ce cas pratique écrit en ton nom : il lui faut une clé avec Élèves › Lire (students:read), Bilans › Lire (bilans:read) et Messages › Écrire (messaging:write), et une offre qui inclut les écritures. Crée la clé dans l'app, conditions d'usage acceptées.

Ce que fait ce cas pratique

1. Déclencheur : chaque lundi, puis GET /me pour coach.first_name, la signature (gratuit).
2. Bilans : GET /bilans?since=<J-14>, toutes les pages. since porte sur updated_at, que bouge aussi un commentaire : on ne garde donc que les student_id des bilans dont submitted_at est supérieur ou égal à J-14.
3. Élèves : GET /students, toutes les pages. Chaque élève absent de cet ensemble reçoit un message, sauf s'il est arrivé il y a moins de 14 jours ou si son contrat est PAUSED ou EXPIRED.
4. Envoi : un POST /operations/messaging.send par élève relancé.

curl -X POST https://api.fitdistance.io/api/partner/v1/operations/messaging.send \
  -H "Authorization: Bearer fd_live_xxxxxxxx" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: bilan-42-2026-10-26" \
  -d '{"text": "Salut Léa, …", "studentId": 42}'

L'Idempotency-Key vaut bilan-<id>-<AAAA-MM-JJ>, avec la date du passage : un rejeu le même jour est remboursé. Voir Écritures et idempotence.

Le message

Salut Léa, je n'ai pas reçu de bilan de ta part depuis deux semaines. Quand tu as un moment, tu peux le remplir dans l'app ? Il m'aide à suivre ton évolution.

Mathias

Ce que ça coûte

Une page lue coûte un crédit, débité avant l'appel ; chaque message envoyé en coûte un. Avec 100 élèves et 40 bilans récents : 3 pages lues avec limit=50, 2 avec limit=200, puis un message par élève relancé. Un paramètre refusé coûte quand même un crédit ; un 401, un 403 ou un 429 ne coûtent rien ; un rejeu est remboursé.

Un premier passage sans rien envoyer

messaging.send n'a pas d'aperçu avec studentId : dry_run: true donne un 400 DRY_RUN_UNSUPPORTED, gratuit. Le premier passage liste donc les élèves sans les prévenir, pour le seul prix des lectures.

Dans n8n

1. Choisis Import from URL… et colle https://fitdistance.io/documentation/api/cas-pratiques/eleve-sans-bilan-relance.n8n.json, ou télécharge le workflow et choisis Import from File…. Choisis l'identifiant Fit'Distance API de Brancher n8n dans chaque nœud HTTP Request.
2. Exécute-le et lis la sortie de Students to remind : un élément par élève, avec son texte.

3. Active Send message, exécute à nouveau, puis active le workflow. Il envoie un message par seconde au plus.

Le texte est en haut du code de Students to remind. La boucle est celle de Brancher n8n, plus un nœud Code, Collect check-ins, qui garde les identifiants des pages lues.

Dans Make

1. Premier module HTTP › Make a request sur GET /me ; planning sur son horloge : chaque lundi.
2. HTTP › Make a request : GET sur https://api.fitdistance.io/api/partner/v1/bilans, limit = 200, since = {{addDays(now; -14)}}. Un filtre sur le lien qui suit : has_more égal à false, pour s'arrêter plutôt que de relancer à tort un élève dont le bilan est sur la page suivante. Puis un Iterator sur data, un filtre sur submitted_at et un Flow Control › Array aggregator sur student_id.
3. HTTP › Make a request : GET sur /students avec limit = 200, un Iterator sur data, puis un filtre : joined_at antérieur à {{addDays(now; -14)}}, contract_status différent de PAUSED et de EXPIRED, et contains(map(<tableau agrégé>; student_id); id) faux.
4. Lis le résultat du filtre, puis ajoute HTTP › Make a request : POST sur /operations/messaging.send, Idempotency-Key = bilan-{{id}}-{{formatDate(now; YYYY-MM-DD)}}, Body content type application/JSON, Body input method JSON string, corps {"text": "…", "studentId": {{id}}}.

Le workflow n8n, lui, lit toutes les pages. Référence : élèves, bilans, envoi d'un message.