Migrer une intégration de la V1 vers la V2
GenderAPI.io V1 reste disponible. Migrez chaque intégration vers la V2 avec la même clé API et le même solde de crédits. Mettez à jour ensemble la route, les champs de requête et l'analyse des réponses : la V2 utilise data pour les résultats et meta pour les informations de requête, d'accès et de facturation.
| GenderAPI.io V1 | GenderAPI.io V2 |
|---|---|
| /api, /api/email, /api/username | POST /api/v2/gender ; utilisez type: name, email ou username, ainsi que value. |
| /api/name/multi/country, /api/email/multi/country, /api/username/multi/country | POST /api/v2/gender/batch ; items accepte plusieurs types d'entrée dans un même lot. |
| /api/phone avec number et address | POST /api/v2/phone/validate ; envoyez number et country, puis lisez data.valid et data.possible. |
| askToAI | options.ai_mode: fallback ; c'est déjà la valeur par défaut des requêtes individuelles |
| forceToGenderize | Même champ facultatif pour les trois types ; jeu de données d'abord, puis IA adaptée aux surnoms |
| Champs de réponse à plat | data pour le résultat ; meta pour l'accès et la facturation |
| Pourcentage probability | confidence sur une échelle de 0 à 1, avec confidence_kind ; les scores de l'IA ne sont pas des probabilités calibrées |
| total_names | data.sample_count, peut valoir null |
| used_credits / remaining_credits | meta.usage.charged_credits / remaining_credits |
| Format d'erreur hérité | Statut HTTP, avec code et action des Problem Details |
| Nouvelles tentatives POST | Chaque nouvelle tentative est une nouvelle opération avec facturation normale |
Mettez à jour et vérifiez votre client
Utilisez le contrat de requête et de réponse V2 pour l'intégration que vous migrez. Vérifiez meta.access.mode, conservez les résultats JSON null, examinez les erreurs par élément des lots et vérifiez la facturation avant de réessayer. Maintenez les intégrations V1 sur leurs chemins actuels jusqu'à la mise à jour de leurs clients.