Brancher Make
Lis tes élèves dans Make avec le module HTTP Make a request, sépare-les avec un Iterator et lis la page suivante avec un second module.
Tu vas lire tes élèves dans un scénario Make avec le module HTTP, puis les séparer avec un Iterator pour traiter un élève à la fois.
Il te faut une clé qui peut lire les élèves, avec Élèves › Lire (students:read) coché. Si tu n'en as pas, crée-la dans l'app, sous Paramètres › Intégrations › Clés API : elle ne s'affiche qu'une fois.
1. Règle le module Make a request
Ajoute le module HTTP › Make a request à ton scénario et remplis :
| Champ | Valeur |
|---|---|
| URL | https://api.fitdistance.io/api/partner/v1/students |
| Method | GET |
| Headers | Authorization : Bearer fd_live_xxxxxxxx |
| Query parameters | limit : 50 |
| Parse response | Yes |
Make propose deux versions de ce module : cette page suit la version 4, et l'ancienne, « HTTP (legacy) » ou version 3, nomme autrement certains champs, comme Query String pour Query parameters.
Pour Headers, ajoute un en-tête nommé Authorization dont la valeur est Bearer fd_live_xxxxxxxx. Remplace fd_live_xxxxxxxx par ta clé, en gardant le mot Bearer, une espace, puis ta clé entière. Pour Query parameters, ajoute un paramètre nommé limit de valeur 50.
Mets Parse response sur Yes : sans cela, Make te rend la réponse en un seul bloc de texte, et tu ne peux pas choisir data ensuite. La clé est écrite dans le module : ne partage pas ce scénario avec quelqu'un qui ne doit pas la voir.
2. Lance le scénario une fois
Lance le scénario une fois, puis ouvre le résultat du module. Il demande le périmètre students:read et coûte un crédit, débité avant l'appel. Tu y trouves trois champs à connaître :
data: les élèves de cette page, 50 au plus.has_more:truequand il reste des pages.next_cursor: le repère de la page suivante, que tu passes danscursor.
Un 401 UNAUTHORIZED veut dire que la clé est absente, mal recopiée ou révoquée : vérifie le mot Bearer. Un 403 SCOPE_MISSING veut dire qu'il manque un périmètre, et details.scope le nomme. Ni l'un ni l'autre ne coûte un crédit. Un paramètre refusé, comme limit=500, donne un 400 VALIDATION et coûte un crédit.
3. Sépare les élèves avec un Iterator
Ajoute un module Iterator après le premier. Dans son champ de liste, choisis data, la liste de la réponse du module HTTP. Make lance ensuite la suite du scénario une fois par élève, avec ses champs, comme id, first_name et last_name.
4. Lis la page suivante
Un module HTTP lit une page. Une page coûte un crédit, quel que soit son nombre d'élèves. Quand has_more vaut true, un second module lit la suite.
Ajoute un Router après le premier module : une branche garde l'Iterator de l'étape 3. Sur l'autre branche, pose un filtre qui ne laisse passer que les cas où has_more vaut true, puis ajoute un second module HTTP › Make a request, réglé comme le premier avec un paramètre de plus :
| Champ | Valeur |
|---|---|
| URL | https://api.fitdistance.io/api/partner/v1/students |
| Method | GET |
| Headers | Authorization : Bearer fd_live_xxxxxxxx |
| Query parameters | limit : 50, cursor : le next_cursor du premier module |
| Parse response | Yes |
Termine cette branche par un second Iterator sur le data de ce module. Si tu ajoutes un filtre comme since, garde-le identique d'un module à l'autre : le repère n'est valable qu'avec les mêmes filtres. Pour dépenser moins, passe limit à 200, le maximum, dans les deux modules HTTP. Chaque page de plus est un module de plus. Pour lire toutes les pages sans les compter, la boucle de n8n ou un script est plus directe.
Ta clé accepte 10 appels par seconde et 300 par minute. Un 429 porte Retry-After, le nombre de secondes à attendre, et ne coûte rien.
La suite
Pour une automatisation complète, suis un cas pratique : un e-mail à chaque nouvel élève, une relance pour les élèves sans bilan, une relance pour les élèves inactifs ou un autre cas pratique de l'accueil. Les cas pratiques qui écrivent le disent en tête de page : leur clé doit pouvoir écrire. Les champs des élèves sont décrits dans la référence.