Anslut Zapier till GenderAPI.io V2

Förbered kontot och källposten

Det här exemplet berikar poster i Mailchimp utifrån e-postadressen. Du behöver åtkomst till käll- och målapplikationen, en kontonyckel för GenderAPI.io och de plattformsfunktioner som HTTP-åtgärden använder. Den här guiden innehåller inga fungerande inloggningsuppgifter och inga anslutna konton.

V1 och V2 använder samma kontonyckel och samma saldo. Innan du konfigurerar en förfrågan som debiteras kontrollerar du nyckeln med GET /api/v2/usage och ser till att meta.access.mode i svaret från den slutpunkten har värdet api_key. En nyckel som saknas eller inte känns igen kan leda till att den delade IP-provperioden används; en automatisering i produktion bör inte använda den obemärkt.

Håll arbetsflödet inaktiverat medan du konfigurerar det. En testprediktion förbrukar vanliga krediter. De här guiderna har granskats mot den offentliga dokumentationen och V2-kontraktet; inget autentiserat arbetsflöde har körts från början till slut på någon plattform för den här publiceringen.

• Autentisering och kostnadsfri kontroll av användningen →

Konfigurera GenderAPI.io V2-förfrågan i Zapier

• Börja med en Mailchimp-utlösare som levererar rätt prenumerantpost. Spara id för målgruppen (Audience) och kontakten och lägg till ett filter före HTTP-åtgärden som hoppar över tomma e-postadresser.
• Välj Webhooks by Zapier och åtgärden POST. Ange URL:en nedan och Payload Type: JSON. Lägg till datafälten type = email, value = prenumerantens mappade e-postadress och options__ai_mode = off.
• Skrivsättet med dubbelt understreck kapslar i Zapier options__ai_mode som options.ai_mode i JSON-kroppen. Kodblocket nedan visar den kropp som API:et tar emot; det är inget fjärde fält som du lägger till i åtgärden.
• Lägg till Authorization med värdet Bearer YOUR_API_KEY i avsnittet Headers. Använd application/json som Content-Type. Skriv inte nyckeln i utlösarfält, i frågesträngen eller i exempelsvar.

Kontrollera JSON-kroppen innan du skickar

Det här exemplet visar fasta indata; det är inget förutsagt resultat. Kontrollera först förfrågans struktur och ersätt sedan value med det mappade källfältet, med korrekt JSON-serialisering. Skicka inte plattformens mappningsuttryck som bokstavlig text till API:et.

För andra indata sätter du type till name, email eller username och anger motsvarande värde i value. Lägg bara till country när du har tillförlitlig kontext: fältet är valfritt och är inte avsett att fastställa bosättningsland.

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

• Fält, typer och standardvärden i förfrågan →

Kontrollera HTTP-steget innan du aktiverar uppdateringar

Webhook-rubriker är inget eget fält för hemligheter: den som kan redigera Zap:en ser dem. Begränsa åtkomsten och dela varken Zap:en eller skärmbilder eller exporter som innehåller inloggningsuppgifter. Zapier erbjuder också API by Zapier med sparade inloggningsuppgifter, men konfigurationen av förfrågans kropp skiljer sig där från det här strukturerade POST-receptet.

Kapsla inte in kroppen: skicka ett enda objekt, ingen lista och ingen array. Välj den strukturerade JSON-åtgärden för mappade kunddata; Custom Request skickar råtext och maskerar inte automatiskt specialtecken i infogade värden.

• Strukturerade webhook-förfrågningar och kapslad JSON i Zapier →
• Anslutningar med inloggningsuppgifter i API by Zapier →
• Beteendet vid upprepning (Replay) i Zapier →

Hantera resultaten identified, unknown och fel separat

Tolka svarskroppen innan du väljer en uppdatering i målsystemet. JSON-sökvägarna nedan avser V2-svarskroppen; din plattform kan kapsla in eller platta ut den. Bekräfta den struktur som faktiskt returneras i ett avgränsat test och spara resultatet tillsammans med källpostens id.

En prediktion fastställer varken en persons identitet eller det kön som personen själv uppger. Förvara den separat från uppgifter som personen själv har lämnat. Fastställ godkännandekriterier utifrån representativa data från ditt eget användningsfall och utvärdera konfidensen från datamängden och AI-konfidensen separat.

• Fullständig dokumentation av V2-svaret →
• Fel, överskridna tidsgränser och beslut om nya försök →

Uppdatera bara den matchande posten i Mailchimp

Granska teståtgärdens tolkade svar och välj fälten för data.gender, data.result_status och de övriga V2-sökvägarna ovan. Fältväljaren i Zapier kan platta ut kapslade beteckningar: utgå från det observerade värdet och den överordnade sökvägen i stället för att förutsätta det äldre fältet probability från den inbyggda kopplingen. Uppdatera bara den Mailchimp-prenumerant vars id har sparats.

Testa grenarna för ett resultat identified, ett resultat unknown och ett fel innan du aktiverar uppdateringar. Med fiktiva exempelsvar kan du kontrollera villkoren för förgreningen utan att skicka en ny prediktion. Uppdateringen i målapplikationen bör bero på kontrollerna ovan och får inte skriva över orelaterade fält eller taggar.

• Svarsfält och okända resultat →
• Noggrannhet och konfidens förklarade →
• Datakällor och den daterade databasprofilen →

Kontrollera nya försök och upprepade debiteringar

Granska inställningarna för Autoreplay och manuell upprepning (Replay) i Zapier innan du aktiverar Zap:en. Att upprepa en misslyckad webhook-åtgärd skickar en ny förfrågan; upprepa inte en lyckad förfrågan bara för att reparera ett senare Mailchimp-steg. Spara prenumerantens ursprungliga id och förfrågans resultat tillsammans.

Varje ny förfrågan till GenderAPI är en egen åtgärd. Deduplicera upprepade källhändelser i ditt eget arbetsflöde innan de skickas, med hjälp av det sparade käll-id:t och bearbetningsstatusen. Källpostens id är ingen nyckel som skyddar mot upprepningar på serversidan.

Ett lyckat resultat unknown är ett fullständigt resultat som debiteras. Vid en överskriden tidsgräns eller ett ofullständigt svar kan resultatet och debiteringen vara okända: spara förfrågans referens om den finns och klarlägg debiteringen innan du skickar förfrågan igen. Respektera rubriken Retry-After när den följer med ett svar om överskriden gräns för förfrågningar.

• Krediter och debiteringsstatus →

Bestäm när AI ska användas

forceToGenderize är valfritt för namn, e-postadresser och användarnamn. När det är aktiverat utelämnar du ai_mode eller använder fallback; off och always kan inte kombineras med det och ger 422. Ett positivt startsaldo räcker för att starta en förfrågan, även om den slutliga debiteringen gör saldot negativt.

Smeknamnsläget kan returnera ett kön tillsammans med name: null. Det kan också ge ett okänt resultat. Varken vanlig AI-reserv eller tolkning av smeknamn garanterar ett korrekt svar eller ett värde som inte är null.

• AI-alternativ och tolkning av smeknamn →
• Krediter och användning →

Granska arbetsflödet innan du ökar volymen

• Kontrollera i ett avgränsat test den JSON som faktiskt serialiseras, de tolkade resultatsökvägarna, åtkomsten med API-nyckel och bekräftelsen av debiteringen. Testa om möjligt hanteringen av resultat unknown och av fel med exempelsvar.
• Klarlägg vilka steg i arbetsflödet som upprepas och vilka kundfält som ändras. Spara källpostens id, det mottagna svaret och förfrågans referens, så att ett senare fel i målsystemet inte kräver ytterligare en förfrågan.
• Aktivera först en liten, kontrollerad körning och granska dess poster och krediter innan du ökar parallelliteten. GenderAPI-krediter och de uppgifter eller operationer som automatiseringsplattformen debiterar är separata kostnader.
• För batchar använder du POST /api/v2/gender/batch med upp till 50 poster vid åtkomst med API-nyckel eller 10 med IP-provperioden. Arrayen items kan kombinera namn, e-postadresser och användarnamn, med uttryckliga alternativ och ett unikt id för varje post. Granska varje resultat: ett svar med HTTP 200 kan innehålla fel i enskilda poster. Batchstödet i en inbyggd koppling måste kontrolleras separat.

• Batchar och fel i enskilda poster →
• Implementeringsguide för Python →
• Implementeringsguide för Node.js →

Vanliga frågor