Connecter GenderAPI.io V2 à Make

Choisissez la connexion Make adaptée à votre contrat

La recette HTTP de ce guide appelle GenderAPI.io V2 à l’adresse https://api.genderapi.io/api/v2/gender. Envoyez type et value dans le corps JSON ; lisez l’estimation dans data et les informations de requête et de facturation dans meta. Les connecteurs natifs ont leurs propres contrats, décrits ci-dessous.

Make référence une application GenderAPI.io proposant des actions pour les prénoms et les adresses e-mail. Sa fiche publique renvoie vers genderapi.io, mais n’indique ni la version exacte de l’endpoint ni le schéma de réponse complet. Examinez la sortie réelle du module choisi avant de modifier le mappage de scénarios existants.

Pour un comportement V2 explicite, utilisez l’application HTTP de Make et la requête ci-dessous. Cette configuration HTTP ne met pas à niveau un module GenderAPI existant : conservez les scénarios opérationnels à part tant que leur remplacement n’a pas été vérifié.

Préparez le compte et l’enregistrement source

Cet exemple enrichit des enregistrements Shopify à partir d’une adresse e-mail. Vous avez besoin d’un accès aux applications source et destination, d’une clé de compte GenderAPI.io et des fonctions de la plateforme utilisées par l’action HTTP. Ce guide ne fournit ni identifiants opérationnels ni comptes connectés.

V1 et V2 utilisent la même clé de compte et le même solde. Avant de configurer une requête facturable, vérifiez la clé avec GET /api/v2/usage et contrôlez que meta.access.mode vaut api_key dans la réponse de cet endpoint. Une clé absente ou non reconnue peut basculer vers l’essai partagé par adresse IP ; une automatisation de production ne doit pas en dépendre à votre insu.

Laissez le workflow désactivé pendant la configuration. Une prédiction de test consomme des crédits normaux. Ces instructions ont été vérifiées à partir de la documentation publique et du contrat V2 ; aucun workflow authentifié n’a été exécuté de bout en bout sur une plateforme pour cette publication.

Authentification et vérification gratuite de la consommation

Configurez la requête GenderAPI.io V2 dans Make

Choisissez le déclencheur client Shopify adapté à votre scénario et chargez un enregistrement de test représentatif. Conservez l’identifiant du client pour la mise à jour finale et ignorez les enregistrements dont l’adresse e-mail est vide.
Ajoutez HTTP > Make a request. Dans l’application HTTP actuelle, choisissez l’authentification API key et créez un identifiant dont la valeur de clé est Bearer YOUR_API_KEY, avec l’emplacement Header et le nom de paramètre Authorization. Utilisez ce stockage d’identifiants plutôt que de placer la clé dans une URL.
Définissez la méthode POST et l’URL ci-dessous. Choisissez application/json pour le corps de la requête et une structure de données comportant les champs texte type et value, ainsi qu’une collection options contenant le champ texte ai_mode. Définissez type sur email et ai_mode sur off, puis associez l’adresse e-mail du client à value.
Activez Parse response. Le corps construit avec une structure de données Make sérialise les valeurs associées en JSON : les prénoms ou adresses contenant des guillemets ne nécessitent aucune concaténation manuelle de texte.

Paramètre HTTP	Valeur	Rôle
`Method`	`POST`	Envoie une requête de prédiction unitaire.
`URL`	`https://api.genderapi.io/api/v2/gender`	Endpoint V2 de prédiction unitaire de GenderAPI.io.
`Authorization`	`Bearer YOUR_API_KEY`	Remplacez l’espace réservé à l’aide des contrôles d’authentification ou d’en-têtes de la plateforme.
`Content-Type`	`application/json`	Envoie un objet contenant un objet options imbriqué, et non des champs de formulaire.
`options.ai_mode`	`off`	Premier test délibéré limité au jeu de données : débit normal de 1 crédit, même si le résultat est unknown.

Vérifiez le corps JSON avant l’envoi

Cet exemple illustre une entrée fixe ; ce n’est pas un résultat prédit. Vérifiez d’abord la structure de la requête, puis remplacez value par le champ source associé en utilisant une sérialisation JSON adaptée. N’envoyez pas à l’API des expressions de mappage de la plateforme sous forme de texte littéral.

Pour une autre entrée, indiquez name, email ou username dans type et fournissez la valeur correspondante dans value. N’ajoutez country que si vous disposez d’un contexte fiable : ce champ est facultatif et ne sert pas à déterminer le pays de résidence.

{
  "type": "email",
  "value": "alex@example.com",
  "options": {
    "ai_mode": "off"
  }
}

Champs de requête, types et valeurs par défaut

Examinez l’étape HTTP avant d’activer les mises à jour

Laissez les redirections désactivées pour cette destination API HTTPS fixe. Si vous changez de version de l’application HTTP de Make, revérifiez les paramètres d’authentification et de corps : leurs contrôles peuvent différer.

Lancez un test délibéré, examinez le bundle de réponse analysé et créez des routes distinctes pour les résultats identifiés acceptés, les résultats inconnus et les échecs opérationnels avant d’ajouter la mise à jour du client.

Séparez les résultats identifiés, inconnus et les échecs

Analysez le corps de la réponse avant de choisir la mise à jour de destination. Les chemins JSON ci-dessous désignent le corps V2 ; votre plateforme peut l’encapsuler ou l’aplatir. Confirmez la structure réellement renvoyée par un test délibéré et conservez le résultat avec l’identifiant de l’enregistrement source.

Une estimation n’établit ni l’identité d’une personne ni le genre qu’elle déclare. Stockez-la séparément des informations fournies par la personne. Définissez vos critères d’acceptation à partir de données représentatives de votre propre usage et évaluez séparément la confiance issue du jeu de données et celle de l’IA.

Contrôle	Valeur ou type attendu	Décision du workflow
`meta.access.mode`	api_key pour ce workflow de compte	Arrêtez le workflow si la valeur est ip_trial et corrigez la clé. Une réponse d’essai réussie ne prouve pas l’authentification du compte et peut déjà avoir consommé des crédits d’essai.
`meta.usage.billing_status`	confirmed ou unconfirmed	Si la valeur est unconfirmed, conservez l’identifiant de requête et faites rapprocher la facturation avant de relancer ou de poursuivre.
`data.result_status / data.gender`	identified avec male ou female ; unknown avec null	Enregistrez les résultats identifiés acceptés dans un champ d’inférence distinct. Conservez unknown sans attribuer de catégorie par défaut.
`data.confidence / data.confidence_kind`	nombre de 0 à 1 ou null ; type de preuve ou null	Interprétez observed_frequency et model_reported séparément ; aucun des deux ne garantit une exactitude universelle.
`data.source / data.sample_count`	dataset, ai ou none / entier ou null	Conservez l’origine de l’estimation. L’IA n’a pas de nombre d’échantillons enregistré ; un effectif du jeu de données n’est pas un score d’exactitude du produit.
`meta.request_id / meta.usage`	référence de requête / objet de consommation	Enregistrez-les avec l’enregistrement du workflow et le résultat. Tenez les clés API et les données personnelles superflues à l’écart des journaux courants.
`Échec HTTP / réponse absente`	Problem Details ou absence de réponse complète	Suspendez la mise à jour et examinez l’erreur et l’état de facturation. Un délai d’attente dépassé ne prouve pas que le serveur n’a rien traité.

Mettez à jour uniquement l’enregistrement Shopify visé

Dans la réponse HTTP analysée, associez les chemins du corps V2 indiqués ci-dessus. Make peut placer le corps sous un libellé de sortie du module : sélectionnez les objets data et meta imbriqués dans le bundle examiné. Mettez à jour uniquement le client dont l’identifiant a été conservé par le déclencheur, dans un champ d’inférence distinct ou selon une politique d’étiquettes définie.

Testez les branches identifiée, inconnue et d’erreur avant d’activer les mises à jour. Des réponses d’exemple fictives permettent d’exercer les conditions de branchement sans envoyer de nouvelle prédiction. La mise à jour de destination doit dépendre des contrôles ci-dessus et ne doit pas écraser de champs ou d’étiquettes sans rapport.

Maîtrisez les relances et les débits répétés

Examinez les gestionnaires d’erreurs de Make et les paramètres des exécutions incomplètes. Certaines erreurs temporaires peuvent être relancées même sans gestionnaire Retry explicite. Une nouvelle tentative du module HTTP peut envoyer une autre requête facturable. Si la requête a abouti mais qu’une mise à jour Shopify ultérieure a échoué, réutilisez la sortie enregistrée pour corriger cette mise à jour.

Chaque nouvelle requête GenderAPI est une opération indépendante. Dédupliquez les événements source répétés dans votre propre workflow avant l’envoi, à l’aide d’un identifiant source enregistré et d’un état de traitement. L’identifiant d’un enregistrement source n’est pas une clé de protection contre les relances côté serveur.

Un résultat unknown réussi est un résultat complet et facturable. En cas de délai dépassé ou de réponse incomplète, le résultat et le débit peuvent être inconnus : conservez la référence de requête lorsqu’elle est disponible et rapprochez la facturation avant de renvoyer la requête. Respectez Retry-After lorsqu’il accompagne une réponse de limitation de débit.

Crédits et états de facturation

Choisissez quand utiliser l’IA

forceToGenderize est facultatif pour les noms, les adresses e-mail et les noms d’utilisateur. Lorsqu’il est activé, omettez ai_mode ou utilisez fallback : la combinaison avec off ou always renvoie une erreur 422. Un solde de départ positif suffit pour lancer une requête, même si le débit final fait passer le solde en dessous de zéro.

L’analyse des pseudonymes peut renvoyer un genre avec name: null. Elle peut aussi renvoyer unknown. Ni le repli IA standard ni l’analyse des pseudonymes ne garantissent une réponse correcte ou non nulle.

Option de la requête	Comportement	Crédits par requête aboutie
options.ai_mode: off	Interroge uniquement le jeu de données.	1 crédit, unknown compris
options.ai_mode: fallback	Interroge d’abord le jeu de données, puis l’IA standard si aucun genre n’est trouvé. C’est le mode par défaut des requêtes individuelles.	1 crédit au total, repli IA compris
options.ai_mode: always	Interroge directement l’IA.	2 crédits
forceToGenderize: true	Interroge d’abord le jeu de données ; si aucun genre n’est trouvé, autorise l’IA à interpréter le sens d’un surnom ou d’un pseudonyme personnel, même sans prénom réel.	1 crédit si le jeu de données résout la requête ; 2 au total si l’IA est utilisée

Validez le workflow avant d’augmenter le volume

Lors d’un test délibéré, vérifiez le JSON réellement sérialisé, les chemins de sortie analysés, l’accès par clé API et la confirmation de la facturation. Testez le routage des résultats inconnus et des échecs avec des réponses fictives lorsque c’est possible.
Identifiez les étapes du workflow qui sont relancées et les champs client qui changent. Conservez l’identifiant de l’enregistrement source, la réponse obtenue et la référence de requête : un échec ultérieur à destination ne doit pas exiger une nouvelle requête.
Activez d’abord une exécution restreinte et contrôlée, puis examinez ses enregistrements et ses crédits avant d’augmenter la concurrence. Les crédits GenderAPI et les tâches ou opérations facturées par la plateforme d’automatisation sont des coûts distincts.
Pour un lot, utilisez POST /api/v2/gender/batch avec jusqu’à 50 éléments en accès par clé API, ou 10 avec l’essai par IP. Le tableau items peut mélanger prénoms, adresses e-mail et noms d’utilisateur, avec des options explicites et un identifiant unique par élément. Examinez chaque résultat : une réponse HTTP 200 peut contenir des échecs partiels. La prise en charge des lots par un connecteur natif doit être vérifiée séparément.

Questions fréquentes

Dois-je coller la clé API dans l’URL de Make ?

Non. Pour la configuration HTTP V2, enregistrez Bearer YOUR_API_KEY dans un identifiant HTTP de type API key, avec l’emplacement Header et Authorization comme nom de paramètre. L’endpoint POST n’accepte pas de paramètre de requête key.

L’exemple HTTP direct autorise-t-il l’IA ?

Le corps de la première requête définit options.ai_mode sur off. Passez délibérément à fallback pour un repli IA ordinaire, pour 1 crédit au total, ou à always pour utiliser directement l’IA, pour 2 crédits. forceToGenderize interroge d’abord le jeu de données : 1 crédit si la requête y est résolue, 2 au total lorsque l’IA est utilisée.

Un résultat inconnu est-il gratuit, ou peut-on le relancer automatiquement sans risque ?

Non. Un résultat unknown réussi est complet et facturable. Une relance est une nouvelle opération. En cas d’erreur de transport ou de facturation non confirmée, examinez la consommation et la référence de requête renvoyées avant de décider de renvoyer la requête.

Ce workflow a-t-il été exécuté dans un compte connecté ?

Non. Les instructions de configuration des plateformes ont été vérifiées le 26 septembre 2026 à partir de leur documentation publique. Les explications sur la requête et la réponse GenderAPI.io V2 ont été vérifiées le 27 septembre 2026. La révision de cette version française, le 28 septembre 2026, porte sur la traduction et ne constitue pas un nouveau test de compte. Testez les champs actuels de l’action choisie, l’authentification, le corps, la réponse et les nouvelles tentatives dans votre propre compte avant d’activer les mises à jour en production.

Documentation de référence

Dernière révision de la version française : 28 septembre 2026. Les consignes propres aux plateformes reposent sur leur documentation publique examinée le 26 septembre 2026 ; cette révision ne constitue pas un nouveau test dans un compte connecté. Consultez la documentation officielle des plateformes pour vérifier la configuration et la disponibilité actuelles.