---
title: "ईमेल से OTP कैसे निकालें: अपने परीक्षण मेलबॉक्स के लिए API गाइड"
description: "अपने Gmail या Outlook परीक्षण मेलबॉक्स से API के ज़रिए OTP पढ़ें। सही मेलबॉक्स, सीमित read अनुमति और हाल के संदेशों के फ़िल्टर से पुराने कोड से बचें।"
url: https://mailera.app/hi/blog/email-otp-api
published: 2026-10-25
updated: 2026-10-25
---

# ईमेल से OTP कैसे निकालें: अपने परीक्षण मेलबॉक्स के लिए API गाइड

अपने मौजूदा Gmail या Outlook मेलबॉक्स से OTP पढ़ें। सीमित अनुमति वाली API कुंजी, हाल के संदेशों के फ़िल्टर और पुराने कोड से बचने की जाँच के साथ।

## OTP भेजना, पढ़ना और सत्यापित करना कैसे अलग हैं?

लॉगिन टेस्ट में ईमेल OTP इस्तेमाल करने के लिए कोड भेजने वाली API और इनबॉक्स पढ़ने वाली API को अलग रखें। आपका परीक्षण ऐप कोड भेजने का अनुरोध करता है। Mailera से आप उस मेलबॉक्स में आया कोड पढ़ते हैं, फिर उसे अपने ऐप के सत्यापन चरण में जमा करते हैं।

यहाँ OTP से मतलब ईमेल में आए एक बार इस्तेमाल होने वाले सत्यापन कोड से है। इस प्रक्रिया का दायरा आपके अपने परीक्षण खाते और आपके नियंत्रण वाले मेलबॉक्स हैं।

| काम | जिम्मेदार प्रणाली | क्या जाँचना है |
| --- | --- | --- |
| OTP माँगना | आपका ऐप या उसकी प्रमाणीकरण सेवा | अनुरोध सही परीक्षण खाते के लिए हुआ |
| संदेश पहुँचना | ईमेल प्रदाता | अपेक्षित मेलबॉक्स में संबंधित संदेश आया |
| OTP पढ़ना | Mailera की API | परिणाम अपेक्षित प्रेषक और परीक्षण से मेल खाता है |
| कोड जमा करना | आपके ऐप का सत्यापन चरण | ऐप ने कोड स्वीकार किया या अस्वीकार |

[Mailera मौजूदा मेलबॉक्स को ऐप से जोड़ता है](https://mailera.app/hi/product); यह नया मेलबॉक्स या ईमेल पता नहीं बनाता। इसलिए पहले वही परीक्षण पता चुनें जिस पर आपका ऐप सत्यापन ईमेल भेजेगा।

![परीक्षण ऐप से मेलबॉक्स और Mailera होकर संदर्भ जाँच तथा ऐप में सत्यापन तक OTP का प्रवाह।](https://mailera.app/media/a78536c34bfed9d5/otp-api-otp-flow-hi-1200.jpg)
_कोड पढ़ने के बाद संदर्भ जाँचें; अस्पष्ट परिणाम को ऐप में जमा न करें।_

## मेलबॉक्स और API कुंजी कैसे तैयार करें?

### 1. परीक्षण मेलबॉक्स जोड़ें

**मेलबॉक्स → मेलबॉक्स जोड़ें** खोलें और **एक मेलबॉक्स** टैब चुनें। मेलबॉक्स जोड़ने के लिए Admin या Leader भूमिका चाहिए। परीक्षण वाले मेलबॉक्स को अलग समूह में रखें, ताकि API कुंजी का दायरा उसी समूह तक सीमित किया जा सके।

Outlook या Microsoft 365 के लिए **मेलबॉक्स जोड़ें** स्क्रीन पर **Microsoft से साइन इन करें** टैब चुनें और Microsoft की OAuth अनुमति प्रक्रिया पूरी करें। इस कनेक्शन में ऐप पासवर्ड इस्तेमाल नहीं होता। प्रदाता के चरण [Microsoft मेलबॉक्स जोड़ने की गाइड](https://mailera.app/hi/providers/microsoft) में हैं। Outlook के लिए [API से सत्यापन कोड पढ़ने की गाइड](https://mailera.app/hi/blog/outlook-otp-api) देखें।

Gmail के लिए **एक मेलबॉक्स** में **ईमेल पता** भरें और **जारी रखें** चुनें। Mailera का Gmail कनेक्शन ऐप पासवर्ड (app password) इस्तेमाल करता है। Google की सलाह है कि जहाँ "Sign in with Google" विकल्प मिले वहाँ उसे प्राथमिकता दें। Mailera के **पासवर्ड** फ़ील्ड में ऐप पासवर्ड भरें, सामान्य Google साइन-इन पासवर्ड नहीं।

Google के अनुसार ऐप पासवर्ड के लिए खाते में दो-चरणीय सत्यापन चालू होना चाहिए। खाते की पात्रता और वर्तमान निर्देश [Google की ऐप पासवर्ड सहायता](https://support.google.com/accounts/answer/185833) में देखें; Mailera वाले चरण [Gmail कनेक्शन गाइड](https://mailera.app/hi/providers/gmail) में हैं। अलग-अलग प्रदाताओं का अंतर समझने के लिए [मेलबॉक्स ऐप पासवर्ड और OAuth की मुख्य गाइड](https://mailera.app/hi/blog/email-app-password-oauth) उपयोगी है।

![Mailera की मेलबॉक्स जोड़ें स्क्रीन में एक मेलबॉक्स और Microsoft से साइन इन करें विकल्प।](https://mailera.app/media/18bafa98aa25d307/oauth-mailera-ai-add-mailbox-hi-1200.jpg)
_प्रदाता के अनुसार अपना मौजूदा परीक्षण मेलबॉक्स जोड़ें।_

### 2. कनेक्शन की जाँच करें

ऐप पासवर्ड वाले फ़ॉर्म में विवरण भरकर **जाँचें और कनेक्ट करें** चुनें। यह कनेक्शन जाँचता है, कोई परीक्षण ईमेल नहीं भेजता। इनकमिंग कनेक्शन सफल होने की जाँच करें।

अगर केवल भेजने वाला कनेक्शन विफल हो, तो **केवल प्राप्ति मोड में सहेजें** चुन सकते हैं, या **विवरण बदलें** से जानकारी सुधारकर **फिर से जाँचें** चुन सकते हैं। इस परीक्षण में OTP आपका ऐप भेजता है; Mailera प्राप्त ईमेल पढ़ता है।

### 3. केवल पढ़ने की अनुमति वाली कुंजी बनाएँ

**सेटिंग्स → API key** टैब खोलें और **API key बनाएँ** चुनें। **पहचानने योग्य नाम** में ऐसा नाम रखें जिससे परीक्षण का उद्देश्य समझ आए। **मेलबॉक्स का दायरा** केवल परीक्षण वाले समूह तक रखें और अनुमतियों में सिर्फ़ `Read` चुनें।

OTP पढ़ने के लिए API का `read` scope पर्याप्त है। इस कुंजी में `send`, `move` या `sync` जोड़ने की जरूरत नहीं है। **समाप्ति** में काम के अनुरूप अवधि चुनें।

नई कुंजी केवल एक बार दिखाई जाती है। उसे अपने सर्वर या परीक्षण वातावरण के सुरक्षित secret store में रखें और वहाँ से `$MAILERA_API_KEY` परिवेश चर में उपलब्ध कराएँ। उसे ब्राउज़र कोड, रिपॉज़िटरी या परीक्षण लॉग में न रखें।

![परीक्षण समूह तक सीमित मेलबॉक्स दायरे और केवल Read अनुमति वाली API कुंजी का फ़ॉर्म।](https://mailera.app/media/db5ef344306d5b30/otp-api-otp-read-key-hi-1200.jpg)
_OTP पढ़ने की कुंजी को परीक्षण समूह और read अनुमति तक सीमित रखें।_

### 4. सही मेलबॉक्स का id चुनें

मेलबॉक्स सूची माँगें:

```bash
curl --silent --show-error \
  'https://mailera.app/api/public/v1/mailboxes' \
  -H "Authorization: Bearer $MAILERA_API_KEY"
```

प्रतिक्रिया की `data` सूची में `email` देखकर अपना परीक्षण मेलबॉक्स पहचानें। उसी प्रविष्टि का `id` `$MAILBOX_ID` में रखें। सूची के पहले मेलबॉक्स को बिना जाँचे न चुनें। `group_id` और `provider` से चयन की अतिरिक्त जाँच कर सकते हैं।

यदि अपेक्षित मेलबॉक्स सूची में नहीं दिखता, तो चुने हुए समूह और कुंजी के दायरे की जाँच करें। तुरंत सभी समूहों की पहुँच देना इस समस्या का सही पहला कदम नहीं है।

## API अनुरोध से हाल का OTP कैसे निकालें?

Mailera के [REST API](https://mailera.app/hi/docs) का आधार URL `https://mailera.app/api/public/v1` है। प्रमाणीकरण के लिए `Authorization: Bearer $MAILERA_API_KEY` हेडर भेजें। कनेक्शन के दूसरे विकल्प [Mailera के डेवलपर पृष्ठ](https://mailera.app/hi/developers) पर हैं।

अनुरोध इस क्रम में करें:

1. परीक्षण शुरू होने का समय और इस्तेमाल हो रहा परीक्षण खाता दर्ज करें।
2. अपने ऐप में उसी खाते के लिए OTP माँगें।
3. चुने हुए मेलबॉक्स से OTP माँगते समय अपेक्षित प्रेषक और विषय के फ़िल्टर लगाएँ। खोज की समय-सीमा छोटी रखें और वर्तमान परीक्षण के हिसाब से चुनें।
4. परिणाम का परीक्षण-संदर्भ जाँचें। उसके बाद ही कोड ऐप में जमा करें।

निम्न उदाहरण में `no-reply@example.com` और `Test sign-in code` काल्पनिक मान हैं। इन्हें अपने ऐप के वास्तविक प्रेषक और विषय से बदलें। `since_minutes=5` उदाहरण की खोज-अवधि है, कोई डिफ़ॉल्ट मान या OTP की वैधता अवधि नहीं।

```bash
curl --silent --show-error --get \
  "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/otp" \
  -H "Authorization: Bearer $MAILERA_API_KEY" \
  --data-urlencode 'from=no-reply@example.com' \
  --data-urlencode 'subject=Test sign-in code' \
  --data-urlencode 'since_minutes=5'
```

| मान | उद्देश्य | चयन करते समय ध्यान दें |
| --- | --- | --- |
| `id` | वह मेलबॉक्स जिसमें कोड खोजना है | ईमेल पता देखकर चुना हुआ `id` इस्तेमाल करें |
| `from` | अपेक्षित प्रेषक से खोज सीमित करना | ऐप के भेजने वाले पते का इस्तेमाल करें |
| `subject` | संबंधित विषय से खोज सीमित करना | अपने सत्यापन ईमेल का अपेक्षित विषय रखें |
| `since_minutes` | हाल की समय-सीमा में खोज सीमित करना | वर्तमान परीक्षण के लिए छोटी, प्रासंगिक अवधि चुनें |

पूरा OTP उत्तर CI के सामान्य लॉग में न छापें। स्थानीय जाँच में भी साझा टर्मिनल रिकॉर्डिंग से बचें। स्क्रीनशॉट या सहायता संदेश में कोड की जगह `<छिपाया गया OTP>` लिखें।

कोड न मिलने पर तुरंत नया OTP माँगना शुरू न करें। पहले उसी अनुरोध के लिए सीमित पुनःप्रयास करें। अपने परीक्षण में अधिकतम प्रयास और अंतिम समय-सीमा पहले से तय रखें; हर प्रयास के बीच अंतर रखें। समय-सीमा खत्म होने पर परीक्षण को विफल दर्ज करें, अनंत प्रतीक्षा में न छोड़ें।

नया OTP माँगने और मौजूदा ईमेल का इंतज़ार करने के चरण अलग रखें। इससे पता रहेगा कि परीक्षण किस अनुरोध का परिणाम खोज रहा है।

## पुराना या दूसरे परीक्षण का OTP मिलने से कैसे बचें?

सिर्फ़ “सबसे नया” कोड चुनना पर्याप्त नहीं है। एक ही मेलबॉक्स पर पास-पास चले दो लॉगिन परीक्षणों में प्रेषक और विषय समान हो सकते हैं। छोटी समय-सीमा खोज को सीमित करती है, लेकिन परिणाम को अपने-आप किसी खास परीक्षण से नहीं जोड़ती।

उदाहरण के लिए, पहला परीक्षण कोड माँगता है और उसके बाद दूसरा परीक्षण भी उसी पते पर कोड माँग देता है। अब मिले हुए कोड को पहले परीक्षण में डालना केवल अनुमान होगा। ऐसी स्थिति में परीक्षण रोकें या दोनों परीक्षणों को अलग मेलबॉक्स पर चलाएँ। एक मेलबॉक्स पर परीक्षण एक के बाद एक चलाकर भी अस्पष्टता घटा सकते हैं।

`since_minutes` को ऐप के OTP समाप्ति-समय का विकल्प न मानें। यह परीक्षण शुरू होने का सटीक समय भी नहीं है। परीक्षण की अपनी समय-सीमा अलग रखें और जरूरत पड़ने पर मूल संदेश देखें।

### संदेश का समय और संदर्भ जाँचें

चुने हुए मेलबॉक्स के Inbox में संदेशों की सूची माँग सकते हैं:

```bash
curl --silent --show-error --get \
  "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages" \
  -H "Authorization: Bearer $MAILERA_API_KEY" \
  --data-urlencode 'folder=inbox' \
  --data-urlencode 'from=no-reply@example.com'
```

सूची में `from.address`, `to`, `subject` और `received_at` देखें। `received_at` को दर्ज किए गए परीक्षण-आरंभ समय से मिलाएँ। संबंधित संदेश का `id` चुनकर उसे `$MESSAGE_ID` में रखें और पूरा संदेश माँगें:

```bash
curl --silent --show-error \
  "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages/$MESSAGE_ID" \
  -H "Authorization: Bearer $MAILERA_API_KEY"
```

पूरे संदेश में `body.text` और `body.html` सामग्री के फ़ील्ड हैं। यदि आपके ऐप के ईमेल में परीक्षण या अनुरोध का कोई पहचान-चिह्न है, तो उससे मिलान करें। पूरे संदेश की सामग्री लॉग में डालने के बजाय जाँच का नतीजा दर्ज करें।

आगे बढ़ने से पहले इन सवालों का स्पष्ट उत्तर होना चाहिए:

- क्या मेलबॉक्स और प्राप्तकर्ता उसी परीक्षण खाते के हैं?
- क्या प्रेषक और विषय अपेक्षित हैं?
- क्या संदेश का समय वर्तमान परीक्षण से मेल खाता है?
- क्या यह संदेश साथ में चल रहे किसी दूसरे अनुरोध के कारण आया हो सकता है?

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

## आम गलतियाँ: OTP न मिले या काम न करे तो क्या जाँचें?

OTP न मिलना, संदेश न पहुँचना और ऐप द्वारा कोड अस्वीकार करना अलग समस्याएँ हैं। नीचे की जाँच से पहले यह तय करें कि प्रक्रिया किस चरण पर रुकी है।

| समस्या | क्या जाँचें | अगला कदम |
| --- | --- | --- |
| गलत मेलबॉक्स चुना गया | `GET /mailboxes` में `email` और `id` | सही `$MAILBOX_ID` लेकर अनुरोध दोहराएँ |
| फ़िल्टर बहुत संकीर्ण हैं | वास्तविक प्रेषक, विषय और संदेश का समय | संदेश सूची देखकर गलत फ़िल्टर सुधारें; बिना वजह पुरानी अवधि न जोड़ें |
| कनेक्शन टूटा है | `GET /mailboxes/{id}/status` (प्रदाता के अनुसार अलग जाँच) | जरूरत होने पर खाते का कनेक्शन बहाल करें |
| सिंक की स्थिति देखनी है | मेलबॉक्स के `sync.last_synced_at` और `sync.state` | सीमित प्रतीक्षा करें; मैनुअल सिंक की अनुमति अलग रखें |
| संदेश Inbox में नहीं है | `GET /mailboxes/{id}/placement` और Junk फ़ोल्डर | संबंधित संदेश की जगह और सामग्री जाँचें |
| ऐप ने कोड अस्वीकार किया | परीक्षण खाता, अनुरोध-संदर्भ और ऐप का परिणाम | इसे OTP पढ़ने की सफलता से अलग सत्यापन-विफलता मानें |

`GET /mailboxes/{id}/status` Microsoft मेलबॉक्स के लिए साइन-इन की सीधे जाँच करता है, जबकि बाकी प्रदाताओं के लिए यह पिछली सिंक की स्थिति के आधार पर बताता है। इसलिए दोनों तरह के परिणामों को कनेक्शन की मौजूदा स्थिति की एक जैसी जाँच न मानें।

अगर कनेक्शन की समस्या Gmail में है और Google खाते का पासवर्ड हाल में बदला है, तो सेटअप में इस्तेमाल किए गए ऐप पासवर्ड की जाँच करें। Google पासवर्ड बदलने पर ऐप पासवर्ड रद्द करता है। ऐसे में ऊपर दिए गए Gmail कनेक्शन के चरणों से नया ऐप पासवर्ड भरकर कनेक्शन बहाल करें।

`GET /mailboxes/{id}/placement` यह देखने के लिए है कि संबंधित ईमेल Inbox या Spam में पहुँचा। इसे OTP पढ़ने या संदेश स्थानांतरित करने वाला endpoint न समझें। Junk में मिला संदेश देखने के लिए चुने हुए मेलबॉक्स के संदेश अनुरोध में `folder=junk` इस्तेमाल कर सकते हैं।

मैनुअल सिंक के लिए `POST /mailboxes/{id}/sync` है, लेकिन उसे अलग `sync` अनुमति चाहिए। केवल `read` वाली कुंजी से यह कार्रवाई नहीं होगी। इसी तरह Junk से संदेश हटाने के लिए `move` अनुमति चाहिए। इन अनुमतियों को OTP पढ़ने की न्यूनतम कुंजी में केवल सुविधा के लिए न जोड़ें।

## OTP और मेलबॉक्स डेटा को सुरक्षित कैसे रखें?

अपने नियंत्रण वाले परीक्षण मेलबॉक्स और परीक्षण खातों तक पहुँच सीमित रखें। साझा स्क्रीनशॉट में OTP के साथ ईमेल पता, संदेश की निजी सामग्री और API कुंजी भी छिपाएँ। परीक्षण के नतीजे में पूरा संदेश सहेजने की जगह इतना दर्ज करें कि कोड मिला, संदर्भ मेल खाया और ऐप ने उसे स्वीकार किया या नहीं।

कुंजी का दायरा परीक्षण समूह तक रखना नुकसान सीमित करने का व्यावहारिक तरीका है। यही सिद्धांत Microsoft भी अपनी [Graph अनुमतियों की गाइड](https://learn.microsoft.com/en-us/graph/auth/auth-concepts) में दोहराता है: ऐप को सिर्फ़ उतनी ही अनुमति माँगनी चाहिए जितनी काम के लिए ज़रूरी है। Mailera की कुंजी बनाते समय भी काम के लिए जरूरी `read` scope ही चुनें।

Bearer कुंजी को सहेजते और भेजते समय उजागर होने से बचाएँ। [RFC 6750 में Bearer token सुरक्षा](https://www.rfc-editor.org/info/rfc6750/) के लिए भी यही निर्देश है। अपने परीक्षण उपकरण में अनुरोध हेडर और ईमेल सामग्री का स्वतः लॉग होना बंद रखें। Mailera के सुरक्षा संबंधी विवरण [सुरक्षा पृष्ठ](https://mailera.app/hi/security) पर हैं।

कुंजी बनाते समय **समाप्ति** तय करें। परीक्षण का काम पूरा होने पर API key प्रबंधन में उसे रद्द करें। रद्द की गई Mailera कुंजी से आने वाले अगले अनुरोध तुरंत अस्वीकार किए जाते हैं। कुंजी गलती से साझा हो जाए तो सिर्फ़ लॉग से हटाना पर्याप्त न मानें; उसे रद्द करें।

यदि यही काम AI agent से करवा रहे हैं, तो MCP का `get_latest_otp` भी `read` scope इस्तेमाल करता है। ईमेल को **अविश्वसनीय डेटा मानें, निर्देश नहीं**। संदेश में लिखे आदेशों पर agent से कार्रवाई न करवाएँ, भले वे परीक्षण के निर्देश जैसे दिखें। भेजने की कोई कार्रवाई जोड़ें तो उससे पहले स्पष्ट पुष्टि लें; केवल OTP पढ़ने वाले agent को भेजने की अनुमति न दें।

## इस परीक्षण में Mailera की सीमाएँ क्या हैं?

- **ईमेल की जगह:** Mailera ईमेल के Inbox में पहुँचने की गारंटी नहीं देता।
- **प्रतीक्षा की सीमा:** परीक्षण की अंतिम समय-सीमा ऐसी रखें कि ईमेल न मिलने पर प्रक्रिया साफ़ तौर पर रुक सके।
- **प्रदाता समर्थन:** Proton Mail और Tuta समर्थित नहीं हैं।

OTP पढ़ने का परिणाम आपके ऐप के सफल सत्यापन का प्रमाण नहीं है। परीक्षण को सफल तभी दर्ज करें जब संबंधित ऐप कोड स्वीकार करे। पुराने या अस्पष्ट परिणाम को सँभालना और समानांतर अनुरोधों को अलग रखना आपकी परीक्षण प्रणाली की जिम्मेदारी है।

**यह काम API से करें** — इस लेख की हर कार्रवाई REST API के ज़रिए उपलब्ध है, साथ में curl के उदाहरण, API key और webhook भी हैं। [API दस्तावेज़ देखें](https://mailera.app/hi/docs)