Un e-mail à chaque nouvel élève

Toutes les heures, tu reçois un e-mail pour chaque élève arrivé depuis le dernier passage. Le cas pratique ne fait que lire tes élèves : l'e-mail part du nœud e-mail de ton outil, pas de l'API. Il te faut une clé avec Élèves › Lire (students:read) et rien d'autre. Si tu n'en as pas, crée-la dans l'app.

Ce que fait ce cas pratique

1. Déclencheur : un passage toutes les heures.
2. Lecture : GET /students avec limit=50 et since égal au dernier passage. Tant que has_more vaut true, une lecture de plus suit next_cursor.
3. Filtre : on garde les élèves dont joined_at est supérieur ou égal au dernier passage. since porte sur updated_at, qui bouge aussi à chaque connexion : sans ce filtre, chaque élève connecté déclencherait un e-mail.
4. E-mail : un message pour toi par élève retenu, avec son nom et sa date d'arrivée.

curl "https://api.fitdistance.io/api/partner/v1/students?limit=50&since=2026-10-26T08:00:00.000Z" \
  -H "Authorization: Bearer fd_live_xxxxxxxx"

Un élève qui attendait ton accord entre dans la liste à l'acceptation, mais son joined_at reste la date de sa demande. Accepté plus d'une heure après, il échappe à ce cas pratique.

Ce que ça coûte

Une page lue coûte un crédit, débité avant l'appel. Un passage lit en général une page, soit 24 crédits par jour. L'e-mail ne coûte rien. Un paramètre refusé coûte quand même un crédit ; un 401, un 403 ou un 429 ne coûtent rien.

Dans n8n

1. Choisis Import from URL… et colle https://fitdistance.io/documentation/api/cas-pratiques/nouvel-eleve-email.n8n.json, ou télécharge le workflow et choisis Import from File….
2. Crée l'identifiant Header Auth de Brancher n8n et nomme-le Fit'Distance API, ou choisis le tien dans chaque nœud HTTP Request.
3. Dans Email me, choisis ton compte SMTP et remplace l'adresse d'exemple par la tienne. Tu peux changer le sujet et le texte.
4. Exécute le workflow une fois, puis active-le.

La boucle est celle de Brancher n8n : More pages? est le nœud If et Students, next page lit la page suivante. Save this run retient la date du passage une fois toutes les pages lues, mais seulement sur un workflow actif : en test, la fenêtre est la dernière heure. Si un passage échoue en route, le suivant relit la même fenêtre et tu peux recevoir un e-mail en double.

Dans Make

1. Premier module HTTP › Make a request (planning sur son horloge : toutes les 60 minutes) : GET sur https://api.fitdistance.io/api/partner/v1/students, en-tête Authorization, limit = 50 et since = {{addHours(now; -1)}}, comme dans Brancher Make, qui lit aussi la page suivante.
2. Iterator sur data, puis un filtre : joined_at postérieur ou égal à {{addHours(now; -1)}}.
3. Email › Send an Email, à ton adresse, avec first_name, last_name et joined_at.

Make ne retient pas de dernier passage : le scénario regarde la dernière heure et doit tourner chaque heure. Référence : élèves.