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

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

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

26 सितंबर 2026 को समीक्षा किया गया Pipedream का सार्वजनिक GenderAPI.io कंपोनेंट पुराना बेस पता https://api.genderapi.io/api इस्तेमाल करता है और name या email, वैकल्पिक country और API कुंजी को क्वेरी स्ट्रिंग पैरामीटर के रूप में भेजता है। प्रकाशित इम्प्लीमेंटेशन एक V1 कनेक्टर है, V2 का JSON एंडपॉइंट नहीं।

आप मौजूदा नेटिव ऑपरेशन को उसके मूल नियमों के साथ इस्तेमाल करते रह सकते हैं, या V2 के लिए एक सामान्य HTTP चरण जोड़ सकते हैं। यह न मानें कि नेटिव कनेक्शन वाले अकाउंट का स्वचालित प्रमाणीकरण इस अलग V2 अनुरोध पर भी लागू होता है: यह तरीका साफ़ तौर पर Bearer हेडर इस्तेमाल करता है।

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

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

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

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

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

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

अपने अकाउंट और वर्कफ़्लो के लिए सही Twilio SendGrid इवेंट या तय समय-सारणी चुनें। एक टेस्ट संपर्क जाँचें, उसकी स्थिर id सेव करें, और डेटा जोड़ने वाले चरण से पहले खाली ईमेल पते वाले रिकॉर्ड छोड़ दें। ट्रिगर के लिए उपलब्ध समय-अंतराल प्लेटफ़ॉर्म की सेटिंग है, GenderAPI का वादा नहीं।
Send any HTTP Request ऑपरेशन जोड़ें, POST चुनें और नीचे दिया URL डालें। JSON बॉडी कॉन्फ़िगर करें: type = email, value = संपर्क का ईमेल पता, options.ai_mode = off।
कुंजी सेव करने के लिए Pipedream के क्रेडेंशियल या एनवायरनमेंट वेरिएबल नियंत्रण इस्तेमाल करें। Authorization को Bearer और उस गोपनीय मान पर सेट करें, और Content-Type को application/json पर। नेटिव प्रमाणीकरण का वह तरीका जारी न रखें जिसमें कुंजी क्वेरी स्ट्रिंग में जाती है, और किसी भी चरण में कुंजी न दिखाएँ।
ऑपरेशन के मैपिंग नियंत्रणों से बॉडी को एक JSON ऑब्जेक्ट के रूप में बनाएँ। संपर्क के मानों को विशेष वर्ण एस्केप किए बिना जोड़कर कच्चा JSON न बनाएँ। सीमित टेस्ट चलाने से पहले अनुरोध का प्रीव्यू जाँचें।

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": "email",
  "value": "alex@example.com",
  "options": {
    "ai_mode": "off"
  }
}

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

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

HTTP चरण से एक्सपोर्ट हुआ रिस्पॉन्स जाँचें और पार्स की गई बॉडी ढूँढें। चुना गया ऑपरेशन बॉडी को टेक्स्ट के रूप में लौटाए, तो data और meta पढ़ने से पहले उसे एक बार पार्स करें। ट्रांसपोर्ट ऑब्जेक्ट का data फ़ील्ड और V2 रिस्पॉन्स बॉडी का data फ़ील्ड एक नहीं हैं।

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

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 या अधूरा रिस्पॉन्स	अपडेट रोकें और त्रुटि व बिलिंग की स्थिति जाँचें। टाइमआउट से यह साबित नहीं होता कि सर्वर ने कोई प्रोसेसिंग नहीं की।

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

ट्रिगर से मिली संपर्क की id को पार्स की गई V2 रिस्पॉन्स बॉडी के साथ सेव करें। ऊपर दी गई परिणाम जाँच पूरी होने के बाद ही SendGrid में योजना के अनुसार कस्टम फ़ील्ड अपडेट करें। संपर्क का खुद दिया गया नाम बनाए रखें: ईमेल पते से अनुमानित data.name सिर्फ़ एक संभावित नाम है, पुष्टि किया गया विकल्प नहीं।

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

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

Pipedream के दस्तावेज़ बताते हैं कि प्लान के अनुसार विफल चरण से स्वचालित दोबारा प्रयास हो सकता है। ये सेटिंग और चुने गए HTTP ऑपरेशन का दोबारा प्रयास वाला व्यवहार जाँचें। डेटा जोड़ने वाले विफल चरण के दोबारा प्रयास से नया शुल्क लग सकता है। टारगेट सिस्टम में बाद में होने वाली विफलता को डेटा जोड़ने वाले चरण के सेव किए गए आउटपुट से ठीक करें।

हर नया 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 रिस्पॉन्स में भी किसी एक आइटम की त्रुटि हो सकती है। नेटिव कनेक्टर बैच प्रोसेसिंग सपोर्ट करता है या नहीं, यह अलग से जाँचना होगा।

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

क्या Pipedream का नेटिव GenderAPI.io ऑपरेशन V2 इस्तेमाल करता है?

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

क्या सीधा 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 को हुई थी। यह समीक्षा किसी जुड़े हुए अकाउंट से किया गया नया टेस्ट नहीं है। मौजूदा कॉन्फ़िगरेशन और उपलब्धता प्लेटफ़ॉर्म के आधिकारिक दस्तावेज़ीकरण में जाँचें।