Connecter GenderAPI.io V2 à Zapier

Préparez le compte et l’enregistrement source

Cet exemple enrichit des enregistrements Mailchimp à 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 Zapier

• Commencez par le déclencheur Mailchimp qui fournit l’abonné visé. Conservez les identifiants d’audience et de contact, puis ajoutez un filtre qui ignore les adresses e-mail vides avant l’action HTTP.
• Choisissez Webhooks by Zapier et son action POST. Indiquez l’URL ci-dessous et Payload Type: JSON. Ajoutez les champs de données type = email, value = l’adresse e-mail de l’abonné associée et options__ai_mode = off.
• La notation à double tiret bas de Zapier imbrique options__ai_mode sous la forme options.ai_mode dans le corps JSON. Le bloc de code ci-dessous montre le corps reçu par l’API ; ce n’est pas un quatrième champ à coller dans l’action.
• Dans Headers, ajoutez Authorization avec la valeur Bearer YOUR_API_KEY. Utilisez application/json comme Content-Type. Ne placez la clé ni dans les champs du déclencheur, ni dans la chaîne de requête, ni dans les exemples de réponse.

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

Les en-têtes de Webhooks ne constituent pas un champ secret dédié : les personnes qui peuvent modifier le Zap les voient. Restreignez l’accès et ne partagez aucun Zap, capture d’écran ou export contenant l’identifiant. Zapier propose aussi API by Zapier avec des identifiants enregistrés, mais la configuration de son corps de requête diffère de cette recette POST structurée.

N’encapsulez pas le corps : envoyez un seul objet, et non une liste ou un tableau. Préférez l’action JSON structurée pour les données client associées ; Custom Request envoie du texte brut et n’échappe pas automatiquement les valeurs insérées.

• Requêtes Webhooks structurées et JSON imbriqué dans Zapier →
• Identifiants de connexion d’API by Zapier →
• Fonctionnement de la relecture (replay) dans Zapier →

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.

• Référence complète des réponses V2 →
• Erreurs et décisions de nouvelle tentative →

Mettez à jour uniquement l’enregistrement Mailchimp visé

Examinez la réponse analysée de l’action de test et sélectionnez les champs correspondant à data.gender, data.result_status et aux autres chemins V2 ci-dessus. Le sélecteur de Zapier peut aplatir les libellés imbriqués : utilisez la valeur et le chemin parent observés au lieu de supposer l’ancien champ probability d’un connecteur natif. Mettez à jour uniquement l’abonné Mailchimp dont vous avez conservé l’identifiant.

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.

• Champs de réponse et résultats inconnus →
• Exactitude et confiance →
• Sources des données et profil du jeu de données →

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

Examinez les paramètres Autoreplay et de relecture manuelle de Zapier avant d’activer le Zap. Relancer une action webhook en échec envoie une nouvelle requête ; ne relancez pas une requête réussie uniquement pour corriger une étape Mailchimp ultérieure. Conservez ensemble les identifiants d’origine de l’abonné et le résultat de la requête.

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.

• Options d’IA et analyse des pseudonymes →
• Crédits et consommation →

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.

• Lots et échecs partiels →
• Guide d’implémentation Python →
• Guide d’implémentation Node.js →

Questions fréquentes