Eine Integration von V1 auf V2 umstellen
GenderAPI.io V1 bleibt verfügbar. Stellen Sie jede Integration mit demselben API-Schlüssel und demselben Credit-Guthaben auf V2 um. V2 hat einen anderen Anfrage- und Antwortvertrag, daher genügt es nicht, nur die URL zu ändern: Aktualisieren Sie Route, Anfragefelder und Antwortverarbeitung gemeinsam. V2 verwendet data für Ergebnisse und meta für Angaben zu Anfrage, Zugang und Abrechnung.
| GenderAPI.io V1 | GenderAPI.io V2 |
|---|---|
| /api, /api/email, /api/username | POST /api/v2/gender mit type: name, email oder username und value. |
| /api/name/multi/country, /api/email/multi/country, /api/username/multi/country | POST /api/v2/gender/batch mit items; Eingabetypen können gemischt werden. |
| /api/phone mit number und address | POST /api/v2/phone/validate mit number und country; lesen Sie data.valid und data.possible. |
| askToAI | options.ai_mode: fallback; Einzelanfragen verwenden fallback bereits standardmäßig |
| forceToGenderize | Dasselbe optionale Feld für alle drei Typen; zuerst Datensatz, dann KI mit Spitznamen-Auswertung |
| Flache Antwortfelder | data für das Ergebnis; meta für Zugang und Abrechnung |
| probability als Prozentwert | confidence auf einer Skala von 0–1 plus confidence_kind; KI-Werte sind keine kalibrierten Wahrscheinlichkeiten |
| total_names | data.sample_count, kann null sein |
| used_credits / remaining_credits | meta.usage.charged_credits / remaining_credits |
| Bisheriges Fehlerformat | HTTP-Status plus Problem Details code und action |
| POST-Wiederholungen | Jeder Wiederholungsversuch ist ein neuer Vorgang mit normaler Abrechnung |
Client aktualisieren und prüfen
Verwenden Sie für die Integration, die Sie migrieren, den Anfrage- und Antwortvertrag von V2. Prüfen Sie meta.access.mode, behalten Sie null-Ergebnisse in JSON bei, prüfen Sie Batch-Fehler pro Eintrag und kontrollieren Sie die Abrechnung vor einer Wiederholung. Belassen Sie V1-Integrationen auf ihren bestehenden Pfaden, bis ihre Clients aktualisiert sind.