Integrately को GenderAPI.io V2 से जोड़ें

अपने API नियमों के अनुसार Integrately का कनेक्शन चुनें

इस गाइड का HTTP तरीका https://api.genderapi.io/api/v2/gender पर GenderAPI.io V2 को कॉल करता है। JSON बॉडी में type और value भेजें। अनुमान data में और अनुरोध व बिलिंग की जानकारी meta में होती है। नेटिव कनेक्टर के अपने नियम हैं, जिनका विवरण नीचे दिया गया है।

Integrately पर GenderAPI.io पेज में genderapi.io का ज़िक्र है और नाम, ईमेल पते तथा ईमेल पते से नाम निकालने के ऑपरेशन दिए गए हैं। पेज पर न आधारभूत API का संस्करण बताया गया है, न आउटपुट की पूरी संरचना। सिर्फ़ ऑपरेशन के नाम से V2 के साथ संगतता की पुष्टि नहीं होती।

Integrately के दस्तावेज़ Webhook/API को बाहर भेजे जाने वाले POST ऑपरेशन के रूप में बताते हैं। इस गाइड में हेडर के मौजूदा नियंत्रणों और JSON एडिटर की अलग से जाँच नहीं की गई है। नीचे दिए V2 HTTP नियम तभी लागू करें जब पक्का हो जाए कि आपका ऑपरेशन Authorization हेडर और नेस्टेड JSON बॉडी भेज सकता है। मौजूदा नेटिव ऑपरेशन अपने फ़ील्ड नियमों के साथ बने रहते हैं।

अकाउंट और मूल रिकॉर्ड तैयार करें

यह उदाहरण पहले नाम के आधार पर Mailchimp के रिकॉर्ड में डेटा जोड़ता है। आपको मूल ऐप और टारगेट ऐप का एक्सेस, GenderAPI.io अकाउंट की कुंजी और HTTP ऑपरेशन के लिए ज़रूरी प्लेटफ़ॉर्म सुविधाएँ चाहिए। इस गाइड में कोई मान्य क्रेडेंशियल या जुड़ा हुआ अकाउंट शामिल नहीं है।

V1 और V2 एक ही अकाउंट कुंजी और एक ही बैलेंस इस्तेमाल करते हैं। शुल्क वाले अनुरोध कॉन्फ़िगर करने से पहले GET /api/v2/usage से कुंजी जाँचें और पक्का करें कि इस एंडपॉइंट के रिस्पॉन्स में meta.access.mode का मान api_key है। कुंजी न होने या पहचानी न जाने पर साझा IP ट्रायल इस्तेमाल हो सकता है। प्रोडक्शन ऑटोमेशन को आपकी जानकारी के बिना इस पर निर्भर नहीं होना चाहिए।

कॉन्फ़िगरेशन के दौरान वर्कफ़्लो बंद रखें। टेस्ट के लिए भेजे गए अनुमान पर भी सामान्य रूप से क्रेडिट लगते हैं। यहाँ दिए गए निर्देश हर प्लेटफ़ॉर्म के सार्वजनिक दस्तावेज़ीकरण और V2 नियमों की समीक्षा पर आधारित हैं। इस लेख के लिए किसी भी प्लेटफ़ॉर्म पर प्रमाणीकरण वाला वर्कफ़्लो शुरू से अंत तक नहीं चलाया गया।

प्रमाणीकरण और मुफ़्त उपयोग जाँच

Integrately में GenderAPI.io V2 अनुरोध कॉन्फ़िगर करें

Mailchimp सब्सक्राइबर वाला ट्रिगर चुनें और एक टेस्ट रिकॉर्ड जाँचें। अपडेट के लिए ऑडियंस (Audience) की id और सब्सक्राइबर की id सेव करें, असली पहले नाम वाला फ़ील्ड चुनें और बिना पहले नाम वाले रिकॉर्ड छोड़ दें।
Webhook/API और URL पर डेटा भेजने वाला संबंधित ऑपरेशन ढूँढें। आगे बढ़ने से पहले उपलब्ध कॉन्फ़िगरेशन जाँचें: नीचे दिए नियमों के लिए प्रमाणीकरण वाले हेडर और नेस्टेड JSON बॉडी ज़रूरी हैं, और यहाँ एडिटर के मौजूदा नियंत्रणों की अलग से जाँच नहीं हुई है।
ऑपरेशन ये ज़रूरतें पूरी करता हो, तो POST और नीचे दिया V2 एंडपॉइंट चुनें। अपने अकाउंट में उपलब्ध नियंत्रणों से पक्का करें कि बाहर जाने वाले अनुरोध में Authorization: Bearer YOUR_API_KEY और Content-Type: application/json शामिल हों।
एक JSON बॉडी बनाएँ जिसमें type = name, value = मैप किया गया पहला नाम, और ai_mode = off वाला options हो। चुने गए ऑपरेशन का अनुरोध प्रीव्यू जाँचें: सपाट फ़ॉर्म पेलोड V2 की JSON बॉडी नहीं है, भले ही Content-Type हेडर सेट हो।
बदलते पहले नामों के लिए प्लेटफ़ॉर्म के मैपिंग या JSON सीरियलाइज़ेशन नियंत्रण इस्तेमाल करें। चुना गया ऑपरेशन नेस्टेड JSON या प्रमाणीकरण वाले हेडर न रख सके, तो कुंजी या JSON को क्वेरी स्ट्रिंग पैरामीटर में लिखने के बजाय HTTP सपोर्ट करने वाला चरण इस्तेमाल करें।

HTTP सेटिंग	मान	उद्देश्य
`Method`	`POST`	एक अनुमान का अनुरोध भेजता है।
`URL`	`https://api.genderapi.io/api/v2/gender`	एकल अनुमान के लिए GenderAPI.io V2 एंडपॉइंट।
`Authorization`	`Bearer YOUR_API_KEY`	प्लेटफ़ॉर्म की प्रमाणीकरण या हेडर सेटिंग में यह प्लेसहोल्डर बदलें।
`Content-Type`	`application/json`	फ़ॉर्म फ़ील्ड के बजाय नेस्टेड options ऑब्जेक्ट वाला एक ऑब्जेक्ट भेजता है।
`options.ai_mode`	`off`	पहला टेस्ट सोच-समझकर सिर्फ़ डेटासेट से: सामान्य शुल्क 1 क्रेडिट, अज्ञात परिणाम पर भी।

भेजने से पहले JSON बॉडी जाँचें

उदाहरण एक तय इनपुट दिखाता है, अपेक्षित परिणाम नहीं। पहले अनुरोध की संरचना जाँचें, फिर सही JSON सीरियलाइज़ेशन के साथ value की जगह मैप किया गया मूल फ़ील्ड रखें। प्लेटफ़ॉर्म के मैपिंग एक्सप्रेशन को शाब्दिक टेक्स्ट के रूप में API को न भेजें।

दूसरे इनपुट के लिए type को name, email या username पर सेट करें और value में उससे जुड़ा मान दें। country सिर्फ़ तभी जोड़ें जब आपके पास भरोसेमंद संदर्भ हो। यह फ़ील्ड वैकल्पिक है और इससे यह तय नहीं होता कि कोई व्यक्ति किस देश में रहता है।

{
  "type": "name",
  "value": "Alice",
  "options": {
    "ai_mode": "off"
  }
}

अनुरोध फ़ील्ड, प्रकार और डिफ़ॉल्ट मान

अपडेट चालू करने से पहले HTTP चरण जाँचें

एक ऑपरेशन का सीमित टेस्ट करें और बाद के चरणों के लिए फ़ील्ड चुनने से पहले लौटाई गई बॉडी जाँचें। एक ही मूल ग्राहक के लिए भी नेटिव GenderAPI.io चरण और Webhook/API चरण अलग-अलग फ़ील्ड लेबल दिखा सकते हैं।

कुंजी को कनेक्शन या अनुरोध के प्रमाणीकरण के लिए बने नियंत्रण में रखें, और सीमित करें कि कौन इस ऑटोमेशन को देख या साझा कर सकता है। इस सार्वजनिक गाइड में कोई मान्य कुंजी, एक्सपोर्ट किया गया कनेक्शन या पहले से कॉन्फ़िगर किया गया ग्राहक अपडेट शामिल नहीं है।

identified, अज्ञात परिणाम और त्रुटियों को अलग-अलग संभालें

टारगेट सिस्टम में अपडेट चुनने से पहले रिस्पॉन्स बॉडी पार्स करें। नीचे की तालिका में JSON पाथ V2 रिस्पॉन्स बॉडी के हैं। आपका प्लेटफ़ॉर्म इन्हें किसी और ऑब्जेक्ट में लपेट सकता है या समतल कर सकता है। सीमित टेस्ट से असली संरचना जाँचें और परिणाम को मूल रिकॉर्ड की id के साथ सेव करें।

अनुमान से किसी व्यक्ति की पहचान या उसका खुद बताया गया लिंग तय नहीं होता। इसे व्यक्ति की दी हुई जानकारी से अलग रखें। अपने उपयोग के प्रतिनिधि डेटा से स्वीकृति के मानदंड तय करें और डेटासेट व AI के कॉन्फिडेंस स्कोर का अलग-अलग आकलन करें।

जाँच	अपेक्षित मान या प्रकार	वर्कफ़्लो में फ़ैसला
`meta.access.mode`	अकाउंट वाले वर्कफ़्लो के लिए api_key	मान ip_trial हो, तो वर्कफ़्लो रोकें और कुंजी ठीक करें। IP ट्रायल से मिला सफल रिस्पॉन्स यह साबित नहीं करता कि अकाउंट से प्रमाणीकरण हुआ, और इससे ट्रायल के क्रेडिट खर्च हो चुके हो सकते हैं।
`meta.usage.billing_status`	confirmed या unconfirmed	मान unconfirmed हो, तो अनुरोध की id सेव करें और दोबारा प्रयास करने या आगे बढ़ने से पहले बिलिंग जाँचें।
`data.result_status / data.gender`	identified होने पर male या female; अज्ञात परिणाम पर null	स्वीकार किया गया identified परिणाम अनुमानित डेटा के लिए तय फ़ील्ड में सेव करें। अज्ञात परिणाम वैसा ही रखें और उसे कोई डिफ़ॉल्ट श्रेणी न दें।
`data.confidence / data.confidence_kind`	0 से 1 के बीच की संख्या या null; साक्ष्य का प्रकार या null	observed_frequency और model_reported का अलग-अलग अर्थ समझें। दोनों में से कोई भी कुल सटीकता की गारंटी नहीं है।
`data.source / data.sample_count`	dataset, ai या none / पूर्णांक या null	अनुमान का स्रोत सेव करें। AI के पास संग्रहीत सैंपल गिनती नहीं होती, और डेटासेट की सैंपल गिनती उत्पाद की सटीकता का पैमाना नहीं है।
`meta.request_id / meta.usage`	अनुरोध का संदर्भ / उपयोग ऑब्जेक्ट	दोनों को वर्कफ़्लो के रिकॉर्ड और परिणाम के साथ सेव करें। API कुंजी या गैर-ज़रूरी निजी डेटा सामान्य लॉग में न लिखें।
`HTTP त्रुटि / कोई रिस्पॉन्स नहीं`	Problem Details या अधूरा रिस्पॉन्स	अपडेट रोकें और त्रुटि व बिलिंग की स्थिति जाँचें। टाइमआउट से यह साबित नहीं होता कि सर्वर ने कोई प्रोसेसिंग नहीं की।

Mailchimp में सिर्फ़ संबंधित रिकॉर्ड अपडेट करें

टारगेट रिकॉर्ड चुनने के लिए सेव की गई Mailchimp ऑडियंस (Audience) की id और सब्सक्राइबर की id इस्तेमाल करें। अनुमानित डेटा के लिए तय फ़ील्ड या स्वीकृत टैग में लिखने से पहले परिणाम की स्थिति और ऊपर दी गई एक्सेस व बिलिंग जाँचों के लिए शर्तें जोड़ें। न मिले लिंग या null मान को कभी संपर्क की डिफ़ॉल्ट श्रेणी में न बदलें।

अपडेट चालू करने से पहले identified परिणाम, अज्ञात परिणाम और त्रुटि, तीनों शाखाओं का अलग-अलग टेस्ट करें। काल्पनिक सैंपल रिस्पॉन्स से नया अनुमान भेजे बिना शाखाओं की शर्तें जाँची जा सकती हैं। टारगेट ऐप में अपडेट इन्हीं जाँचों पर निर्भर होना चाहिए और उससे असंबंधित फ़ील्ड या टैग नहीं बदलने चाहिए।

दोबारा प्रयास और दोहरे शुल्क को नियंत्रित करें

Integrately के दस्तावेज़ स्वचालित दोबारा प्रयास का विवरण देते हैं, जिसमें पूरी कंपनी पर लागू होने वाली सेटिंग भी शामिल हैं। यह ऑटोमेशन चालू करने से पहले संबंधित नीति और गतिविधि इतिहास जाँचें; साझा सेटिंग बदलने से पहले दूसरे वर्कफ़्लो पर उसके असर का आकलन करें। दोहराया गया हर HTTP अनुरोध एक अलग और शुल्क वाला अनुरोध है। पूरे हो चुके आउटपुट सेव करें, ताकि बाद की Mailchimp विफलता नया अनुरोध भेजे बिना ठीक की जा सके।

हर नया GenderAPI अनुरोध एक अलग ऑपरेशन है। भेजने से पहले सेव की गई मूल id और प्रोसेसिंग की स्थिति से वर्कफ़्लो में दोहराए गए मूल इवेंट हटाएँ। मूल रिकॉर्ड की id सर्वर पर दोहराव रोकने वाली कुंजी नहीं है।

पूरा हुआ अज्ञात परिणाम एक पूरा और शुल्क वाला परिणाम है। टाइमआउट या अधूरे रिस्पॉन्स पर परिणाम और बिलिंग, दोनों अज्ञात हो सकते हैं: अनुरोध का संदर्भ मिला हो, तो उसे सेव करें और अनुरोध दोबारा भेजने से पहले बिलिंग जाँचें। अनुरोध-सीमा पार होने वाले रिस्पॉन्स में Retry-After हेडर हो, तो उसका पालन करें।

क्रेडिट और बिलिंग की स्थिति

तय करें कि AI कब इस्तेमाल करना है

नामों, ईमेल पतों और यूज़रनेम के लिए forceToGenderize वैकल्पिक है। इसे चालू करने पर ai_mode छोड़ दें या fallback इस्तेमाल करें; off और always का इससे टकराव होता है और 422 लौटता है। अनुरोध शुरू करने के लिए पॉज़िटिव शुरुआती बैलेंस काफ़ी है, भले ही अंतिम शुल्क के बाद बैलेंस शून्य से नीचे चला जाए।

निकनेम मोड name: null के साथ लिंग लौटा सकता है। यह अज्ञात परिणाम भी लौटा सकता है। न सामान्य AI फ़ॉलबैक और न ही निकनेम का अनुमान सही या non-null जवाब की गारंटी देता है।

अनुरोध का विकल्प	व्यवहार	हर सफल अनुरोध पर क्रेडिट
options.ai_mode: off	सिर्फ़ डेटासेट इस्तेमाल करें।	1, अज्ञात परिणाम पर भी
options.ai_mode: fallback	पहले डेटासेट, फिर लिंग न मिलने पर सामान्य AI। एकल अनुरोध का डिफ़ॉल्ट यही है।	कुल 1, AI फ़ॉलबैक सहित
options.ai_mode: always	सीधे AI से पूछें।	2
forceToGenderize: true	पहले डेटासेट, फिर AI को निजी निकनेम या छद्मनाम समझने की अनुमति, असली पहले नाम के बिना भी।	डेटासेट से परिणाम मिलने पर 1; AI इस्तेमाल होने पर कुल 2

प्रोसेसिंग बढ़ाने से पहले वर्कफ़्लो जाँचें

सीमित टेस्ट से असल में सीरियलाइज़ किया गया JSON, पार्स किए गए परिणाम पाथ, API कुंजी वाला एक्सेस और बिलिंग की पुष्टि जाँचें। हो सके, तो सैंपल रिस्पॉन्स से अज्ञात परिणाम और त्रुटियों का व्यवहार भी जाँचें।
तय करें कि वर्कफ़्लो के कौन-से चरण दोबारा चलते हैं और कौन-से ग्राहक फ़ील्ड बदलते हैं। मूल रिकॉर्ड की id, मिला रिस्पॉन्स और अनुरोध का संदर्भ सेव करें, ताकि टारगेट सिस्टम बाद में विफल हो तो दोबारा अनुरोध न भेजना पड़े।
पहले एक छोटा नियंत्रित रन चालू करें और समानांतर प्रोसेसिंग बढ़ाने से पहले रिकॉर्ड और क्रेडिट जाँचें। GenderAPI के क्रेडिट और ऑटोमेशन प्लेटफ़ॉर्म का टास्क या ऑपरेशन शुल्क दो अलग खर्च हैं।
बैच प्रोसेसिंग के लिए POST /api/v2/gender/batch इस्तेमाल करें: API कुंजी के साथ ज़्यादा से ज़्यादा 50 आइटम और IP ट्रायल में ज़्यादा से ज़्यादा 10। items ऐरे में नाम, ईमेल पते और यूज़रनेम मिलाए जा सकते हैं, और हर आइटम के साथ साफ़ तौर पर तय विकल्प और एक यूनिक id होनी चाहिए। हर परिणाम अलग से जाँचें: HTTP 200 रिस्पॉन्स में भी किसी एक आइटम की त्रुटि हो सकती है। नेटिव कनेक्टर बैच प्रोसेसिंग सपोर्ट करता है या नहीं, यह अलग से जाँचना होगा।

अक्सर पूछे जाने वाले सवाल

क्या पुराने नेटिव ऑपरेशन के probability फ़ील्ड को V2 के confidence फ़ील्ड से मैप किया जा सकता है?

पहले रिस्पॉन्स के नियम जाँचें। सीधे भेजा गया V2 अनुरोध data.confidence और data.confidence_kind लौटाता है, जिनका मान 0 से 1 के बीच की संख्या या null होता है। ऐसा कोई आधार नहीं है कि नेटिव कनेक्टर के फ़ील्ड लेबल और मानों का दायरा इन पाथ से मेल खाते हैं।

क्या सीधा HTTP उदाहरण AI इस्तेमाल करता है?

पहले अनुरोध की बॉडी में options.ai_mode का मान off है। सामान्य स्वचालित AI फ़ॉलबैक के लिए यह मान सोच-समझकर fallback करें, जिस पर कुल 1 क्रेडिट लगता है; सीधे AI के लिए always करें, जिस पर 2 क्रेडिट लगते हैं। forceToGenderize पहले डेटासेट में खोजता है: डेटासेट से परिणाम मिलने पर 1 क्रेडिट और AI इस्तेमाल होने पर कुल 2 क्रेडिट लगते हैं।

क्या अज्ञात परिणाम मुफ़्त है और क्या उसे अपने-आप दोबारा भेजना सुरक्षित है?

नहीं। पूरा हुआ अज्ञात परिणाम एक पूरा और शुल्क वाला परिणाम है। हर दोबारा प्रयास एक नई खोज है। ट्रांसपोर्ट त्रुटि या बिलिंग की पुष्टि न होने पर, अनुरोध दोबारा भेजने का फ़ैसला करने से पहले लौटाया गया उपयोग डेटा और अनुरोध का संदर्भ जाँचें।

क्या यह वर्कफ़्लो किसी जुड़े हुए अकाउंट से चलाकर देखा गया है?

नहीं। प्लेटफ़ॉर्म के कॉन्फ़िगरेशन निर्देशों की समीक्षा 26 सितंबर 2026 को सार्वजनिक दस्तावेज़ीकरण के आधार पर की गई। GenderAPI.io V2 अनुरोध और रिस्पॉन्स के विवरण की समीक्षा 27 सितंबर 2026 को हुई। इस हिंदी संस्करण की 29 सितंबर 2026 की समीक्षा अनुवाद की जाँच है, किसी अकाउंट से किया गया नया टेस्ट नहीं। प्रोडक्शन अपडेट चालू करने से पहले अपने अकाउंट में चुने गए ऑपरेशन के मौजूदा फ़ील्ड, प्रमाणीकरण, अनुरोध बॉडी, रिस्पॉन्स और दोबारा प्रयास का व्यवहार जाँचें।

स्रोत और दस्तावेज़ीकरण

हिंदी संस्करण की पिछली समीक्षा 29 सितंबर 2026 को हुई। प्लेटफ़ॉर्म की जानकारी उनके सार्वजनिक दस्तावेज़ीकरण पर आधारित है, जिसकी समीक्षा 26 सितंबर 2026 को हुई थी। यह समीक्षा किसी जुड़े हुए अकाउंट से किया गया नया टेस्ट नहीं है। मौजूदा कॉन्फ़िगरेशन और उपलब्धता प्लेटफ़ॉर्म के आधिकारिक दस्तावेज़ीकरण में जाँचें।