Déplacer une intégration de la v1 vers la v2
La V1 reste disponible. Migrez les intégrations individuelles lorsque vous êtes prêt en utilisant la même clé et le même solde créditeur. La V2 est un contrat de demande et de réponse différent, donc changer uniquement l'URL n'est pas suffisant.
| Concept V1 | équivalent V2 |
|---|---|
| Points de terminaison distincts pour le nom, l'adresse e-mail et le nom d'utilisateur | POST /api/v2/gender avec type et value |
| Séparer plusieurs points de terminaison | POST /api/v2/gender/batch avec items |
| askToAI | options.ai_mode : fallback ; les requêtes uniques sont déjà par défaut fallback |
| forceToGenderize | Même champ facultatif pour les trois types ; ensemble de données d'abord, puis IA sensible aux surnoms |
| Champs de réponse plats | data pour le résultat ; meta pour l'accès et la facturation |
| pourcentage probability | confidence sur une échelle de 0 à 1 plus confidence_kind ; Les scores d’IA ne sont pas des probabilités calibrées |
| total_names | data.sample_count, nullable |
| used_credits / remaining_credits | meta.usage.charged_credits / remaining_credits |
| Format d'erreur hérité | Statut HTTP plus Problem Details code et action |
| Nouvelles tentatives de POST | Chaque nouvelle tentative est une nouvelle opération avec facturation normale |
Mettez à jour et vérifiez votre client
Utilisez le contrat de demande et de réponse v2 pour l'intégration que vous migrez. Vérifiez meta.access.mode, conservez les résultats JSON null, inspectez les erreurs de lot par article et vérifiez la facturation avant de réessayer. Conservez les intégrations v1 sur leurs chemins existants jusqu'à ce que leurs clients aient été mis à jour.