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

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

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

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

V2 का साफ़ तौर पर तय व्यवहार चाहिए, तो Make का HTTP ऐप नीचे दिए अनुरोध के साथ इस्तेमाल करें। यह HTTP कॉन्फ़िगरेशन मौजूदा GenderAPI मॉड्यूल को अपडेट नहीं करता। जब तक विकल्प की जाँच न हो जाए, चल रहे सिनेरियो को अलग से चलने दें।

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

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

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

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

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

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

अपने सिनेरियो के लिए सही Shopify ग्राहक ट्रिगर चुनें और एक प्रतिनिधि टेस्ट रिकॉर्ड लोड करें। अंतिम अपडेट के लिए ग्राहक की id सेव करें और खाली ईमेल पते वाले रिकॉर्ड छोड़ दें।
HTTP > Make a request जोड़ें। मौजूदा HTTP ऐप में API key प्रमाणीकरण चुनें और क्रेडेंशियल बनाएँ: कुंजी का मान Bearer YOUR_API_KEY, स्थान Header और पैरामीटर का नाम Authorization। कुंजी को URL में लिखने के बजाय क्रेडेंशियल प्रबंधन का यही तरीका इस्तेमाल करें।
मेथड POST पर सेट करें और नीचे दिया URL डालें। बॉडी के लिए application/json चुनें और एक डेटा संरचना इस्तेमाल करें: टेक्स्ट फ़ील्ड type और value, और टेक्स्ट फ़ील्ड ai_mode वाला एक options संग्रह। type को email और ai_mode को off पर सेट करें, फिर ग्राहक का ईमेल पता value से मैप करें।
Parse response चालू करें। Make में डेटा संरचना से बनी बॉडी मैप किए गए मानों को 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 चरण जाँचें

इस तय HTTPS API टारगेट के लिए रीडायरेक्ट बंद रखें। Make के HTTP ऐप का संस्करण बदलें, तो प्रमाणीकरण और बॉडी की सेटिंग दोबारा जाँचें, क्योंकि नियंत्रण अलग हो सकते हैं।

एक सीमित टेस्ट चलाएँ, पार्स किए गए रिस्पॉन्स वाला बंडल जाँचें, और ग्राहक अपडेट जोड़ने से पहले स्वीकार किए गए identified परिणाम, अज्ञात परिणाम और रन की त्रुटि के लिए अलग-अलग रूट बनाएँ।

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

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

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

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

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

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

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

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

क्या Make में API कुंजी URL में लिखनी होगी?

नहीं। V2 के HTTP कॉन्फ़िगरेशन में Bearer YOUR_API_KEY को API key प्रकार के क्रेडेंशियल के रूप में सेव करें, जिसका स्थान Header और पैरामीटर का नाम Authorization हो। POST एंडपॉइंट क्वेरी स्ट्रिंग में key पैरामीटर स्वीकार नहीं करता।

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