अपने सब्सक्राइबर को SubSovereign पर माइग्रेट करना

RevenueCat, Adapty, Qonversion या अपने स्वयं के बैकएंड से आ रहे हैं? आपके मौजूदा सब्सक्राइबर आपके साथ आते हैं। यह गाइड आयात (import) और — उतनी ही महत्वपूर्ण — कटओवर प्रक्रिया को कवर करती है, क्योंकि असली जोखिम कटओवर में है।

पहले यह पढ़ें। आयात सुरक्षित है और बार-बार चलाया जा सकता है। योजना की ज़रूरत कटओवर के समय होती है, क्योंकि जब तक आप अपने स्टोर नोटिफ़िकेशन हमारी ओर नहीं मोड़ते, नवीनीकरण अब भी आपके पुराने प्रदाता को ही पहुँचते रहेंगे। §2 चलाने से पहले §4 की योजना बनाएँ।

माइग्रेशन के दो हिस्से — योजना बनाने से पहले पढ़ें

हर माइग्रेशन में दो तंत्र होते हैं, और इन्हें अलग-अलग समझना ही सहज स्थानांतरण और न निभा पाने वाले वादे के बीच का अंतर है।

क्लाइंट-साइड री-वैलिडेशन ही गारंटी है। जैसे ही आपका ऐप हमारा SDK शिप करता है, हर सब्सक्राइबर का डिवाइस अगली बार ऐप खोलने पर अपनी मौजूदा रसीद दोबारा भेजता है। पहचानकर्ता स्वयं Apple या Google से आता है — मौजूदा, सही और पूर्ण। यह हर स्टोर के लिए काम करता है, किसी से निर्यात (export) की आवश्यकता नहीं, और यह पुराना पहचानकर्ता नहीं ढो सकता। जो भी सब्सक्राइबर आपका ऐप खोलता है, वह संरचनात्मक रूप से सही ढंग से माइग्रेट हो जाता है।

आयात त्वरक (accelerator) है। यह इसलिए है ताकि आपके सब्सक्राइबर अगली बार ऐप खोलने से पहले ही बाहर न हो जाएँ, और आपकी पहले दिन की रिपोर्टिंग खाली न दिखे। यह वही कॉपी करता है जो आपका पिछला प्रदाता जानता था।

दोनों क्यों: सब्सक्राइबर ऐप बहुत अलग-अलग अंतराल पर खोलते हैं। जो व्यक्ति छह सप्ताह तक आपका ऐप नहीं खोलता, केवल री-वैलिडेशन के भरोसे वह छह सप्ताह तक बिना अधिकार वाला दिखेगा। आयात उसे पहले ही क्षण से निरंतरता देता है; री-वैलिडेशन उसे प्रामाणिक बनाता है।

🚩 यदि आप केवल एक ही रख सकते हैं, तो री-वैलिडेशन रखें। ऐसा आयात जो किसी स्टोर के लिए मिलान-योग्य पहचानकर्ता नहीं दे सकता (नीचे देखें), उन सब्सक्राइबरों के लिए माइग्रेशन नहीं है — वह एक ऐसा रिकॉर्ड है जो चुपचाप समाप्त हो जाएगा।

आपका पिछला प्रदाता वास्तव में क्या दे सकता है

आयात को originalTransactionId चाहिए, और प्रदाता क्या देता है यह स्टोर के अनुसार बदलता है। योजना बनाने से पहले अपना जाँच लें:

प्रदाता	Apple	Google
RevenueCat	✅ डेटा निर्यात में `original_transaction_id` होता है।	⚠️ निर्यात Order ID देता है, जो purchase token नहीं है — यह एक अलग पहचानकर्ता है, जिस पर नवीनीकरण नोटिफ़िकेशन मेल नहीं खाएगा। उनका v2 API और भी ख़राब है: यह केवल नवीनतम ट्रांज़ैक्शन आईडी दिखाता है, जो हर नवीनीकरण पर बदल जाती है।
Adapty / Qonversion	योजना बनाने से पहले निर्यात में Apple की original transaction ID की जाँच करें।	जाँचें कि आपको purchase token मिलता है या कोई ऑर्डर/ट्रांज़ैक्शन संदर्भ। इसकी पुष्टि करें, अनुमान न लगाएँ।
Superwall	⚠️ योजना बनाने से पहले पुष्टि करें। वे अपनी स्वयं की अधिकार, ख़रीद और रसीद-सत्यापन परत चलाते हैं, इसलिए पहचानकर्ता उनके पास मौजूद है — खुला प्रश्न यह है कि निर्यात आपको Apple की `original_transaction_id` देता है या केवल Superwall का अपना सब्सक्रिप्शन संदर्भ।	⚠️ वही प्रश्न, वही उत्तर: योजना बनाने से पहले लिखित रूप में तय करें कि आपको purchase token मिलता है या कोई ऑर्डर/ट्रांज़ैक्शन संदर्भ।
आपका अपना बैकएंड	जो आपने ख़रीद के समय संग्रहीत किया — आमतौर पर सही मान।	संभवतः आपके पास purchase token पहले से है, क्योंकि सत्यापन के लिए वह आवश्यक था।
Stripe	लागू नहीं	लागू नहीं — हम आपका Stripe खाता सीधे पढ़ते हैं, किसी निर्यात की आवश्यकता नहीं। §3b देखें।

🚩 इसलिए RevenueCat से आने पर Apple की ओर का आयात साफ़-सुथरा होता है, और Google सब्सक्राइबरों को मिलान-योग्य पहचानकर्ता के साथ आयात नहीं किया जा सकता। यह ऐसी बात नहीं जिसे हम कोड से हल कर सकें: जिस पहचानकर्ता की हमें ज़रूरत है, वह उन डेटा में मौजूद ही नहीं है जो आपको मिल सकते हैं। वे सब्सक्राइबर क्लाइंट-साइड री-वैलिडेशन से आते हैं — SDK शिप करें, नोटिफ़िकेशन मोड़ें (§4), और उनमें से हर एक अगली बार ऐप खोलने पर सही ढंग से माइग्रेट हो जाएगा। निरंतरता के लिए Apple की ओर आयात करें, और Google को स्वयं ठीक होने दें।

1. आपको क्या चाहिए

आपका सब्सक्राइबर निर्यात, जिसमें प्रत्येक सक्रिय अधिकार के लिए एक पंक्ति हो (प्रारूप नीचे देखें)।
एक प्रोडक्ट मैपिंग। आपके निर्यात की हर प्रोडक्ट आईडी को पहले आपके किसी एक एक्सेस स्तर से जोड़ा जाना चाहिए — डैशबोर्ड → आपका ऐप → प्रोडक्ट्स। 🚩 आयात यह अनुमान नहीं लगाएगा कि कौन-सा स्तर देना है। बिना मैप किया गया प्रोडक्ट अस्वीकार कर दिया जाता है और रिपोर्ट किया जाता है, क्योंकि अनुमान लगाना उसी सुरक्षा को दरकिनार करने का रास्ता होगा जो किसी ग्राहक को वह स्तर दावा करने से रोकती है जो उसने ख़रीदा ही नहीं।
उस संगठन का एडमिन लॉगिन जिसके पास ऐप का स्वामित्व है। व्यूअर आयात नहीं कर सकते: यह बड़ी संख्या में सशुल्क पहुँच प्रदान करता है।

2. प्रारूप

प्रत्येक सब्सक्राइबर अधिकार के लिए एक JSON ऑब्जेक्ट:

{
  "userId": "user_12345",
  "email": "person@example.com",
  "store": "apple",
  "productId": "pro_monthly",
  "originalTransactionId": "1000000987654321",
  "expiresAt": "2027-01-01T00:00:00Z",
  "willRenew": true,
  "status": "active"
}

फ़ील्ड	आवश्यक	टिप्पणी
`userId`	हाँ	आपका अपना उपयोगकर्ता पहचानकर्ता — वही जो आपका ऐप हमारे SDK को भेजता है।
`store`	हाँ	`apple` · `google` · `amazon` · `roku` · `stripe`
`productId`	हाँ	आपकी प्रोडक्ट मैपिंग में मौजूद होना चाहिए, अन्यथा पंक्ति अस्वीकार हो जाती है।
`originalTransactionId`	हाँ	🚩 नीचे देखें। Apple की original transaction ID, Google का purchase token, या प्रदाता की सब्सक्रिप्शन आईडी।
`status`	हाँ	`active` · `trialing` · `grace_period` · `expired` · `lifetime` · `cancelled` · `refunded` · `billing_failed`
`expiresAt`	नहीं	ISO 8601. `lifetime` के लिए छोड़ दें।
`amazonUserId`	Amazon के लिए	🚩 Amazon का अपना उपयोगकर्ता पहचानकर्ता, उनके SDK से — आपके ऐप का उपयोगकर्ता पहचानकर्ता नहीं। Amazon रसीद को (वह आईडी, `receiptId`) से खोजता है, इसलिए इसके बिना अधिकार का कभी पुनः सत्यापन नहीं हो सकेगा। इसके बिना Amazon पंक्तियाँ अस्वीकार कर दी जाती हैं।
`email`, `willRenew`	नहीं

🚩 `originalTransactionId` वही फ़ील्ड है जो तय करता है कि यह काम करेगा या नहीं

यह केवल हमारे लिए एक कुंजी नहीं है — यही वह तरीका है जिससे कोई नवीनीकरण महीनों बाद सब्सक्राइबर को दोबारा खोज पाता है। जब Apple या Google नवीनीकरण के लिए सर्वर नोटिफ़िकेशन भेजते हैं, मिलान इसी पहचानकर्ता पर होता है।

इसके बिना आयात की गई पंक्ति सबसे बुरी क़िस्म की विफलता पैदा करती है: पहले दिन सब कुछ सही दिखता है, और फिर सब्सक्राइबर अपने अगले नवीनीकरण पर चुपचाप पहुँच खो देता है, बिना कहीं कोई त्रुटि दर्ज हुए।

इसीलिए हम ऐसी पंक्तियाँ स्वीकार करने के बजाय अस्वीकार करते हैं। इसके बिना आयात करना कोई शॉर्टकट नहीं, बल्कि टाली गई विफलता है।

🚩 हर प्रदाता हर स्टोर के लिए यह फ़ील्ड नहीं दे सकता — ऊपर की तालिका देखें। जहाँ आपका निर्यात इसे वास्तव में नहीं दे सकता (RevenueCat + Google ज्ञात मामला है), वहाँ कोई मान गढ़कर इसे दरकिनार न करें: कोई भी प्लेसहोल्डर ठीक वही चुपचाप होने वाली नवीनीकरण विफलता पैदा करेगा जिसका वर्णन यहाँ किया गया है। जिन स्टोर के लिए आपके पास वास्तविक पहचानकर्ता हैं उन्हें आयात करें, और बाक़ी को क्लाइंट-साइड री-वैलिडेशन पर छोड़ दें।

3. इसे चलाएँ — हमेशा पहले ड्राई रन

यह अनुभाग CSV / निर्यात मार्ग है, जो Apple, Google, Amazon और Roku के लिए उपयोग होता है। Stripe के लिए §3b पर जाएँ — हम आपका खाता सीधे पढ़ते हैं और यहाँ बनाने को कुछ नहीं है।

सबसे आसान तरीक़ा डैशबोर्ड है: Subscriber Migration (Insights → Customers) → From an export। निर्यात को CSV या JSON के रूप में पेस्ट करें, या फ़ाइल लोड करें। यह पृष्ठ पहले पंक्तियों की जाँच करता है और जब तक आप न कहें तब तक कुछ नहीं लिखता; बड़ी फ़ाइलों को आपके लिए बैच में बाँट देता है; और हर अस्वीकृत पंक्ति को पंक्ति संख्या सहित सूचीबद्ध करता है, ताकि आप उन्हें उसी फ़ाइल में ठीक कर सकें जो वास्तव में आपके पास है। यदि आप स्क्रिप्ट लिखना पसंद करते हैं तो नीचे दिया गया API बिल्कुल यही करता है।

🚩 ये पंक्तियाँ एक दावा हैं, पुष्टि नहीं। निर्यात वही है जो आपके पिछले प्रदाता ने आपको सौंपा, इसलिए आयात की गई पंक्तियाँ असत्यापित आती हैं और पुनः जाँच क़तार (§6) में शामिल हो जाती हैं, जहाँ हम बाद में उन्हें वास्तविक स्टोर से मिलाते हैं। सीधे Stripe से पढ़ी गई पंक्तियाँ (§3b) अलग हैं — वे पहले से पुष्ट होकर आती हैं।

ड्राई रन ही डिफ़ॉल्ट है। कुछ भी लिखवाने के लिए आपको स्पष्ट रूप से कहना पड़ता है।

curl -X POST https://api.miimagineai.com/api/v1/apps/YOUR_APP_ID/import/subscribers \
  -H "Authorization: Bearer $DASHBOARD_TOKEN" -H 'Content-Type: application/json' \
  -d '{ "source": "revenuecat", "rows": [ … अधिकतम 1000 पंक्तियाँ … ] }'

आपको एक रिपोर्ट वापस मिलती है:

{
  "dryRun": true, "received": 1000, "accepted": 987, "newUsers": 964,
  "missingTransactionIds": 6,
  "unmappedProducts": ["legacy_annual_v1"],
  "rejected": [ { "index": 12, "code": "unmapped_product", "reason": "…" } ]
}

पुष्टि करने से पहले ये तीन संख्याएँ पढ़ें:

missingTransactionIds — वे पंक्तियाँ जो नवीनीकरण पर कहीं नहीं पहुँचेंगी। निर्यात ठीक करें, आगे न बढ़ें।
unmappedProducts — इन्हें मैप करें, फिर दोबारा चलाएँ।
newUsers — इससे कितने सब्सक्राइबर बनेंगे। यदि संख्या ग़लत लगे, तो संभवतः आपका userId फ़ील्ड सही पहचानकर्ता नहीं है।

जब रिपोर्ट साफ़ हो, "dryRun": false जोड़ें और उसे दोबारा भेजें।

बैचिंग और पुनः आरंभ

प्रति अनुरोध अधिकतम 1000 पंक्तियाँ भेजें; एक बड़ा माइग्रेशन कई बैच का होता है। आयात idempotent है — वही बैच दोबारा भेजने पर डुप्लिकेट बनने के बजाय अद्यतन होता है, इसलिए बीच में रुक गई स्क्रिप्ट को शुरू से दोबारा चलाया जा सकता है। ग़लत पंक्ति रिपोर्ट कर दी जाती है और छोड़ दी जाती है; वह अपने साथ की सही पंक्तियों को कभी नहीं गिराती।

यह क्या अस्वीकार करेगा, और क्यों

कोड	अर्थ
`missing_transaction_id`	ऊपर देखें। सबसे महत्वपूर्ण।
`unmapped_product`	पहले प्रोडक्ट मैप करें; हम स्तर का अनुमान नहीं लगाएँगे।
`transaction_owned_by_another_user`	वह स्टोर ट्रांज़ैक्शन इस ऐप में पहले से किसी दूसरे खाते का है। एक ट्रांज़ैक्शन, एक स्वामी — आमतौर पर मर्ज किया गया खाता या निर्यात में ग़लत डेटा।
`invalid_store` / `invalid_status` / `invalid_expiry`	ख़राब स्वरूप वाला मान।

3b. Stripe — हम आपका खाता सीधे पढ़ते हैं

Stripe इकलौता स्टोर है जो "मेरे सभी सब्सक्राइबर कौन हैं?" का उत्तर दे सकता है। Apple, Google, Amazon और Roku केवल "क्या यह रसीद अब भी वैध है?" का उत्तर देते हैं, एक बार में एक रसीद। इसलिए Stripe के लिए न कोई निर्यात माँगना है और न कोई CSV बनाना: डैशबोर्ड में Subscriber Migration (Insights → Customers) आपके खाते को पढ़कर आयात कर देता है।

शुरू करने से पहले, दो चीज़ें तैयार होनी चाहिए, और पृष्ठ आपको बता देगा यदि वे नहीं हैं:

आपकी Stripe सीक्रेट कुंजी, Apps → store credentials के अंतर्गत संग्रहीत। प्लेटफ़ॉर्म स्तर पर कोई विकल्प नहीं है और कभी नहीं होगा — आपकी कुंजी के बिना आयात किसी और का डेटा पढ़ने के बजाय बंद होकर विफल हो जाता है।
आपके प्रोडक्ट स्तरों से मैप किए गए हों। Price (price_…) या Product (prod_…) में से कोई भी मैप करें; दोनों काम करते हैं। बिना मैप किए प्रोडक्ट अनुमान लगाने के बजाय अस्वीकार किए जाते हैं, जो सही व्यवहार है, कोई ख़राबी नहीं।

फिर हमें बताएँ कि आपके ऐप का उपयोगकर्ता पहचानकर्ता Stripe में कहाँ है — सब्सक्रिप्शन मेटाडेटा, कस्टमर मेटाडेटा, या स्वयं Stripe कस्टमर आईडी। 🚩 कोई डिफ़ॉल्ट नहीं है और हम अनुमान नहीं लगाएँगे। Stripe ग्राहक को cus_… के रूप में जानता है; वह आपका कौन-सा उपयोगकर्ता है यह केवल आप जानते हैं, और ग़लत होने पर यह शोर मचाकर विफल नहीं होता — यह एक सब्सक्राइबर की सशुल्क पहुँच किसी और के खाते को दे देता है।

पहले पूर्वावलोकन करें। पूर्वावलोकन कुछ नहीं बदलता और ठीक-ठीक दिखाता है कि क्या होगा: कितनी सब्सक्रिप्शन पढ़ी गईं, कितनी आयात होंगी, और हर वह जो अस्वीकार होगी — कारण सहित, सरल भाषा में। आयात से पहले अस्वीकृतियाँ पढ़ें: वह ठीक करने योग्य चीज़ों की सूची है, शोर नहीं।

बड़े खातों को कई अनुरोधों में स्वतः पढ़ा जाता है; पृष्ठ दर-सीमा के भीतर रहने के लिए अपनी गति स्वयं नियंत्रित करता है और प्रगति दिखाता रहता है।

यह क्या अस्वीकार करता है, और ये सही उत्तर क्यों हैं

कोड	अर्थ
`never_paid`	सब्सक्रिप्शन `incomplete` है — पहला भुगतान कभी पूरा नहीं हुआ। इसे आयात करना उस व्यक्ति को सशुल्क पहुँच देना होगा जिसने कभी भुगतान ही नहीं किया।
`access_expired`	स्थिति पहुँच देती है, पर बिलिंग अवधि पहले ही समाप्त हो चुकी है। यहाँ पहुँच स्थिति से तय होती है, इसलिए इसे आयात करना अनिश्चितकालीन पहुँच देना होगा।
`ambiguous_product`	एक ही सब्सक्रिप्शन की मदें दो अलग-अलग स्तरों पर मैप होती हैं। हम चुनने के बजाय अस्वीकार करते हैं — ऊँचा चुनना माइग्रेशन के रास्ते से आया स्तर-उन्नयन होगा, और पहला चुनना मनमाना होगा।
`no_user_id`	जहाँ देखने को आपने कहा था वहाँ ऐप का उपयोगकर्ता पहचानकर्ता नहीं मिला। ऊपर देखें: अनुमान लगाने के लिए यही सबसे ख़तरनाक है।
`unmapped_product`	प्रोडक्ट मैप करें, फिर दोबारा चलाएँ।

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

Stripe की पंक्तियाँ पहले से सत्यापित क्यों आती हैं

आयात की गई पंक्ति सामान्यतः तब तक एक दावा मानी जाती है जब तक हम उसे स्टोर से पुष्ट न कर लें (§6)। Stripe की पंक्तियाँ अलग हैं: उन्हें आपके क्रेडेंशियल से Stripe के अपने API के ज़रिए पढ़ा गया है, इसलिए वे पहले से स्टोर-पुष्ट होकर आती हैं। यह उद्गम (provenance) के बारे में कथन है, Stripe के बारे में नहीं — भविष्य में जिस भी भुगतान प्रोसेसर को हम सीधे पढ़ेंगे, वह भी ऐसा ही व्यवहार करेगा, और किसी व्यक्ति द्वारा दी गई पंक्ति चाहे किसी भी स्टोर का नाम ले, दावा ही बनी रहती है।

API पसंद करते हैं? यह पृष्ठ POST /apps/:appId/import/stripe का क्लाइंट है; वही विकल्प हैं dryRun, userIdSource, userIdKey, और पेजिंग के लिए startingAfter।

4. 🚩 कटओवर — आयात से पहले इसकी योजना बनाएँ

आयात स्थिति की प्रतिलिपि बनाता है। यह भविष्य को पुनर्निर्देशित नहीं करता। जब तक आप अपने स्टोर सर्वर नोटिफ़िकेशन SubSovereign की ओर नहीं मोड़ते, नवीनीकरण, रद्दीकरण और रिफ़ंड अब भी आपके पुराने प्रदाता को ही जाते रहेंगे।

अनुशंसित क्रम:

आयात करें (यह गाइड)। अब आपके अधिकार दोनों प्रणालियों में मौजूद हैं।
समानांतर चलाएँ। पुराने प्रदाता को सक्रिय रखें और तुलना करें। अभी कुछ स्थानांतरित नहीं हुआ है।
हमारे SDK वाला ऐप बिल्ड शिप करें। अधिकार हमारी ओर से तय होते हैं, और चूँकि आपने वही ट्रांज़ैक्शन पहचानकर्ता आयात किए हैं, मौजूदा सब्सक्राइबर बिना कुछ किए अपनी पहुँच बनाए रखते हैं।
स्टोर नोटिफ़िकेशन हमारे webhook एंडपॉइंट पर मोड़ें (Apple App Store Server Notifications, Google Real-Time Developer Notifications)। असली स्विच यही है।
आयात दोबारा चलाएँ ताकि उस अवधि में जो कुछ बदला हो वह भी आ जाए। यह idempotent है — यही इस चरण का उद्देश्य है।
एक पूरा नवीनीकरण चक्र साफ़-सुथरा बीत जाने के बाद ही पुराने प्रदाता को बंद करें।

5. आयात किया गया अधिकार क्या है — और क्या नहीं

आयात किया गया अधिकार आपके पिछले प्रदाता के कहने पर दी गई सशुल्क पहुँच है। हमने उसे Apple या Google से स्वयं अभी तक जाँचा नहीं है।

हम इसे छिपाने के बजाय ईमानदारी से दर्ज करते हैं: आयात की गई पंक्तियों में imported_at और import_source होते हैं, और उनका store_verified_at तब तक ख़ाली रहता है जब तक अधिकार वास्तविक स्टोर से पुष्ट न हो जाए। इसलिए "इनमें से कौन-से हमने भरोसे पर दिए थे?" ऐसा प्रश्न है जिसका किसी भी समय सटीक उत्तर मौजूद रहता है।

🚩 यदि कभी कोई आँकड़ा ग़लत लगे तो यह मायने रखता है। आयातित और सत्यापित अधिकार एक ही श्रेणी के तथ्य नहीं हैं, और उन्हें एक जैसा मानने वाला ऑडिट भ्रामक होगा।

6. आयात को स्टोर से पुनः सत्यापित करना

आयात के बाद आप हमसे प्रत्येक अधिकार की वास्तविक स्टोर से जाँच करवा सकते हैं:

curl -X POST https://api.miimagineai.com/api/v1/apps/YOUR_APP_ID/import/verify \
  -H "Authorization: Bearer $DASHBOARD_TOKEN" -H 'Content-Type: application/json' \
  -d '{ "limit": 50 }'

प्रत्येक पंक्ति तीन में से एक परिणाम के साथ लौटती है:

परिणाम	अर्थ
verified	स्टोर ने पुष्टि कर दी। हम आयातित के बजाय स्टोर की समाप्ति तिथि और नवीनीकरण फ़्लैग अपनाते हैं — वही प्रामाणिक स्रोत है।
mismatch	स्टोर ने आयात का खंडन किया: कोई सक्रिय सब्सक्रिप्शन नहीं, या किसी अन्य प्रोडक्ट के लिए सक्रिय सब्सक्रिप्शन।
unverifiable	हमें उपयोगी उत्तर नहीं मिल सका — दर-सीमा, क्रेडेंशियल की समस्या, या क्षणिक त्रुटि। यह खंडन नहीं है।

🚩 mismatch कभी पहुँच नहीं छीनता। अधिकार में कुछ नहीं बदलता; केवल सत्यापन कॉलम लिखे जाते हैं, और विसंगति किसी व्यक्ति के निर्णय के लिए सामने रखी जाती है। "स्टोर ने पुष्टि नहीं की" और "यह सब्सक्राइबर अधिकारी नहीं है" अलग-अलग कथन हैं, और स्टोर API पहला उत्तर ऐसे कारणों से दे सकता है जिनका आपके ग्राहक से कोई लेना-देना नहीं। हम इस आधार पर किसी भुगतान करने वाले सब्सक्राइबर को रद्द करने को तैयार नहीं हैं — विशेषकर उसे जो अभी-अभी हमारे पास आया है। DECISIONS.md #70 देखें।

इसे बैच में चलाएँ (डिफ़ॉल्ट 50, अधिकतम 200) — स्टोर API पर दर-सीमाएँ हैं और ये कॉल आपके स्टोर क्रेडेंशियल का उपयोग करते हैं। GET /apps/YOUR_APP_ID/import/status वर्तमान स्थिति दिखाता है:

{ "imported": 4820, "verified": 4776, "awaiting": 44, "mismatch": 11, "unverifiable": 33 }

इसके लिए अभी कोई स्वचालित शेड्यूल नहीं है, और यह जानबूझकर है — हम आपके स्टोर क्रेडेंशियल को बिना निगरानी के, ऐसे टाइमर पर नहीं चलाना चाहते जिसकी आपने माँग नहीं की। जब आपको सुविधाजनक लगे तब चलाएँ; यह idempotent है और पुनः आरंभ किया जा सकता है।