मॉडपैक ऑथर API: एक्टिवेशन कोड और अपडेट
एक पेड मॉडपैक ऑथर Millida Hosting API के ज़रिए एक्टिवेशन कोड कैसे जारी कर सकता है और अपडेट कैसे पब्लिश कर सकता है: मॉडपैक वर्ज़न, आर्काइव अपलोड, पब्लिकेशन, रोलबैक, कोड स्टेटस और वेबहुक।
6 सितंबर 2026 को अपडेट किया गया
आपको कोड लिखने की ज़रूरत नहीं है। नीचे बताई गई हर चीज़ अब बटन के रूप में भी उपलब्ध है: अगर आपका मॉडपैक आपके Millida अकाउंट से लिंक है, तो आपकी प्रोफ़ाइल में “My modpacks” टैब दिखता है — वहाँ आप वर्ज़न अपलोड कर सकते हैं, कार्ड एडिट कर सकते हैं और लैंडिंग पेज बना सकते हैं। लिंक नहीं है — हमें लिखें, हम लिंक कर देंगे। API उनके लिए है जो अपने CI से डिप्लॉय करते हैं।
यह आर्टिकल उन पेड मॉडपैक के ऑथर के लिए है जो उन्हें खुद बेचते हैं और सर्वर इंस्टॉलेशन हमें सौंप देते हैं। खरीदार को कुछ डाउनलोड करने की ज़रूरत नहीं: वह कोड डालता है और डिप्लॉय किया हुआ मॉडपैक पा लेता है। उसकी तरफ़ से यह कैसा दिखता है, यह देखने के लिए एक्टिवेशन कोड से पेड मॉडपैक पढ़ें।
शुरू करने के लिए क्या चाहिए
- हमें अपने मॉडपैक का सर्वर आर्काइव भेजें — रूट में
mods/वाली.zip(जैसेServer Files/जैसी रैपर के बिना) या.mrpack। आर्काइव हमारे प्राइवेट स्टोरेज में रखा जाता है, और लिंक कभी बाहर शेयर नहीं किया जाता। - हमें कोर, गेम वर्ज़न और मिनिमम मेमोरी बताएँ — विज़ार्ड इन्हीं से उन प्लान को फ़िल्टर करता है जिन पर मॉडपैक नहीं चलेगा।
- हमसे एक मॉडपैक key (
key, जैसेarcania) और एक issuing token लें — आपकी साइट इसी से कोड जनरेट करती है।
टोकन सिर्फ़ एक बार दिखाया जाता है: हम सिर्फ़ उसका फ़िंगरप्रिंट रखते हैं। अगर वह खो जाए, तो हमें दोबारा जारी करने के लिए कहें — पुराना काम करना बंद कर देगा।
यह स्कीम कैसे काम करती है
- पेमेंट आप खुद लेते हैं, अपनी तरफ़।
- पेमेंट के बाद आपकी साइट हमारी API को कॉल करती है और एक्टिवेशन कोड पाती है।
- आप कोड खरीदार को देते हैं — ईमेल, बॉट या “thank you” पेज पर।
- खरीदार हमारी तरफ़ कोड डालता है और पेड प्लान पर मॉडपैक वाला सर्वर पा लेता है।
- सर्वर पर मॉडपैक की फ़ाइलें लॉक रहती हैं:
modsको पैनल से या SFTP से डाउनलोड नहीं किया जा सकता।
फ़िज़िकली, खरीदार के हाथ कभी सर्वर मॉडपैक नहीं लगता — सिर्फ़ एक चलता हुआ सर्वर।
Endpoint और authorization
Base URL — https://millida.net/v2/hosting.
टोकन X-Pack-Token हेडर में भेजा जाता है। यह JWT या Bearer टोकन नहीं है — यह आपके मॉडपैक के लिए एक अलग सीक्रेट है।
X-Pack-Token: mpk_pack_XXXXXXXXXXXXXXXX
Content-Type: application/json
टोकन आपके सर्वर पर रहता है — इसे environment variables में रखें, frontend कोड में नहीं।
कोड जारी करें
POST /v2/hosting/packs/{key}/keys
| फ़ील्ड | टाइप | डिफ़ॉल्ट | यह क्या करता है |
|---|---|---|---|
count | number 1–200 | 1 | एक कॉल में कितने कोड जनरेट करने हैं |
note | string up to 120 | — | आपका नोट: ऑर्डर नंबर, खरीदार का निकनेम |
maxServers | number 1–20 | 1 | एक कोड कितने सर्वर पर एक्टिवेट किया जा सकता है |
expiresAt | ISO date | — | कोड की एक्सपायरी तारीख़ |
curl -X POST https://millida.net/v2/hosting/packs/arcania/keys \
-H "X-Pack-Token: $PACK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"count": 1, "note": "order 4821"}'
{
"code": "A7K2-9MHD-4RTP-QW38",
"codes": ["A7K2-9MHD-4RTP-QW38"]
}
code फ़ील्ड बैच का पहला कोड है, जो कम्पैटिबिलिटी के लिए रखा गया है; जब count > 1 हो, तो codes इस्तेमाल करें।
कोड सिर्फ़ यहीं मिलते हैं और कहीं नहीं। हम उनका हैश रखते हैं — पासवर्ड की तरह। अगर कोड खो जाए, तो हम उसे रिकवर नहीं कर सकते: नया जारी करें और पुराना रिवोक करें।
लिमिट 30 रिक्वेस्ट प्रति मिनट प्रति मॉडपैक है। एक कॉल में 200 कोड तक के बैच खास तौर पर सेल के लिए हैं: एक-एक रिक्वेस्ट की जगह बल्क में जनरेट करें।
कोड के साथ क्या हुआ
GET /v2/hosting/packs/{key}/keys?limit=100
[
{
"codeHint": "A7K29MHD",
"note": "order 4821",
"maxServers": 1,
"usedCount": 1,
"state": "spent",
"expiresAt": null,
"revokedAt": null,
"createdAt": "2026-08-03T12:20:11.000Z"
}
]
कोड खुद रिस्पॉन्स में नहीं होते और हो नहीं सकते। codeHint कोड की शुरुआत है — इससे आप रो को अपने ऑर्डर से मैच कर सकते हैं।
स्टेट: free — इस्तेमाल नहीं हुआ, spent — इस्तेमाल हो गया, expired — एक्सपायर हो गया, revoked — आपने रिवोक कर दिया।
एक कोड चेक करें
POST /v2/hosting/packs/{key}/keys/status, body {"code": "A7K2-9MHD-4RTP-QW38"}.
रिस्पॉन्स वही रो होती है जो लिस्ट में है। कोड body में जाता है, URL में नहीं: URL प्रॉक्सी लॉग और ब्राउज़र हिस्ट्री में पहुँच जाते हैं, और एक्टिवेशन से पहले कोड एक चालू key है।
हाइफ़न और केस से फ़र्क़ नहीं पड़ता: a7k29mhd4rtpqw38 भी A7K2-9MHD-4RTP-QW38 की तरह ही मिल जाएगा।
कोड रिवोक करें
POST /v2/hosting/packs/{key}/keys/revoke, body {"code": "..."}.
इसे रिफ़ंड, गलती से जारी किए गए कोड या विवाद के लिए इस्तेमाल करें। रिवोक करने से आगे के एक्टिवेशन ब्लॉक हो जाते हैं, लेकिन पहले से डिप्लॉय किया हुआ मॉडपैक हटता नहीं — जिस खरीदार ने एक्टिवेट कर लिया, उसका सर्वर चलता रहता है।
एक्टिवेशन webhook
अगर आप हमें webhook URL देते हैं, तो कोड रिडीम होते ही हम उसे कॉल करेंगे:
POST <your-address>
X-Millida-Pack: arcania
Content-Type: application/json
{
"event": "pack.activated",
"packKey": "arcania",
"codeHint": "A7K29MHD",
"serverId": "cm4x...",
"activatedAt": "2026-08-04T09:14:02.000Z"
}
कॉल साइन नहीं की जाती: आप उसी टोकन से keys/status के ज़रिए इसे वेरिफ़ाई कर सकते हैं — codeHint से आप अपनी रो ढूँढकर state: "spent" देख लेंगे। इस तरह आपको दूसरा सीक्रेट रखने की ज़रूरत नहीं पड़ती।
Webhook रिस्पॉन्स का इंतज़ार किए बिना भेजा जाता है और रिट्राई नहीं होता: अगर आपका सर्वर डाउन था, तब भी एक्टिवेशन हो चुका होता है, और आप इसे कोड लिस्ट में देख सकते हैं। URL पब्लिक होना चाहिए — हम इंटरनल या लोकल एड्रेस कॉल नहीं करते। रीडायरेक्ट फ़ॉलो नहीं किए जाते।
मॉडपैक कार्ड
GET /v2/hosting/packs/{key} पब्लिक है, टोकन की ज़रूरत नहीं। यह वही लौटाता है जो खरीदार देखता है: नाम, कोर, वर्ज़न, मिनिमम मेमोरी, प्लान लिस्ट और प्रोटेक्शन फ़्लैग। रिस्पॉन्स में आर्काइव लिंक नहीं होता।
आपकी साइट के “Buy” पेज के लिए यह काम का है: प्लान की ज़रूरतें एक ही सोर्स से आती हैं और हमारे विज़ार्ड में बताई गई बातों से अलग नहीं होंगी।
अपने कार्ड के storefront फ़ील्ड आप खुद एडिट करते हैं: टोकन के साथ PATCH /v2/hosting/packs/{key} ये फ़ील्ड लेता है — name, authorName, authorUrl, iconUrl, webhookUrl। सेल की शर्तें (paidOnly, requireKey, lockFiles, planCodes), storefront में मॉडपैक चालू करना और JVM launch flags टोकन से नहीं बदले जा सकते — ये आपके साथ हमारा एग्रीमेंट और हमारे नोड्स हैं, इसलिए इनके बारे में हमें लिखें।
मॉडपैक अपडेट
पहले अपडेट का मतलब था हमें ईमेल करना और इंतज़ार करना। अब आप खुद वर्ज़न पब्लिश करते हैं, और सर्वर ओनर उसे अपने पैनल में चुनते हैं।
मुख्य बात: हम किसी का अपडेट चुपचाप नहीं करते। मॉडपैक वर्ज़न के बीच शिफ़्ट होना वर्ल्ड के साथ इनकम्पैटिबल हो सकता है, और फ़ैसला सर्वर ओनर करता है। पब्लिश किया गया वर्ज़न वही है जो नए सर्वर पाते हैं और जो हम पहले से डिप्लॉय किए गए सर्वर को ऑफ़र करते हैं; पिछले वर्ज़न लिस्ट में रहते हैं, और आप उन्हीं पर रह सकते हैं या रोलबैक कर सकते हैं।
यह साइकल कैसा दिखता है
# 1. Create a version
curl -X POST https://millida.net/v2/hosting/packs/arcania/versions \
-H "X-Pack-Token: $PACK_TOKEN" -H "Content-Type: application/json" \
-d '{"label":"1.5.0","changelog":"Updated Create to 0.5.1, fixes crash on portals","minRamMb":10240}'
# 2. Upload the archive in chunks (32 MB each), addressing by offset
curl -X POST "https://millida.net/v2/hosting/packs/arcania/versions/1.5.0/archive?offset=0" \
-H "X-Pack-Token: $PACK_TOKEN" -H "Content-Type: application/octet-stream" \
--data-binary @part0.bin
# 3. Say the archive is finished, and publish after parsing
curl -X POST https://millida.net/v2/hosting/packs/arcania/versions/1.5.0/finish \
-H "X-Pack-Token: $PACK_TOKEN" -H "Content-Type: application/json" \
-d '{"archiveSha256":"<sha256 of archive>","publish":true}'
# 4. Wait for parsing
curl https://millida.net/v2/hosting/packs/arcania/versions/1.5.0 -H "X-Pack-Token: $PACK_TOKEN"
वर्शन
| फ़ील्ड | टाइप | यह क्या करता है |
|---|---|---|
label | 40 तक स्ट्रिंग | वर्शन नंबर: लैटिन अक्षर, अंक, डॉट, हाइफ़न, अंडरस्कोर। अपरिवर्तनीय: एक ही लेबल के साथ अलग-अलग फ़ाइलें शिकायत की जाँच को अंदाज़े का खेल बना देती हैं |
changelog | 4000 तक स्ट्रिंग | क्या बदला — सर्वर मालिक अपडेट करने से पहले इसे पढ़ता है |
core, gameVersion | स्ट्रिंग | अगर सर्वर सेटअप किसी दूसरे कोर या गेम वर्शन पर चला गया हो |
loaderBuild, javaVersion | स्ट्रिंग | लोडर बिल्ड और Java के लिए पिन, अगर वर्शन को इसकी ज़रूरत हो |
minRamMb | नंबर | इस ख़ास वर्शन के लिए मेमोरी की न्यूनतम सीमा। जिसके पास काफ़ी नहीं होगा, उसे कारण दिखेगा और उसकी वर्ल्ड नहीं जाएगी |
archiveSha256 | हेक्स 64 | हम पार्स करने से पहले जाँचते हैं: अधूरी पहुँची आर्काइव को अस्वीकार करना बेहतर है, बजाय उसे आधा खोलने के |
अपलोड
POST /v2/hosting/packs/{key}/versions/{label}/archive?offset=N, बॉडी — .zip का एक चंक, Content-Type: application/octet-stream। चंक 32 MB तक, पूरी आर्काइव 4 GB तक।
चंक को ऑफ़सेट से संबोधित किया जाता है, “अंत में जोड़ें” से नहीं: बीच में टूटा चंक पहले ही आंशिक रूप से फ़ाइल में पहुँच चुका होता है, और दोबारा कोशिश वही बाइट्स दूसरी बार जोड़ देगी — आर्काइव चुपचाप ख़राब पहुँचेगी। जवाब में uploadedBytes मिलता है, जिससे रुकावट के बाद अपलोड फिर से शुरू किया जाता है।
पार्सिंग
POST .../finish तुरंत जवाब देता है (status: "processing"), जबकि पार्सिंग बैकग्राउंड में चलती है: गीगाबाइट आकार के सर्वर सेटअप को खोलने में कई मिनट लगते हैं। स्थिति GET .../versions/{label} से पढ़ें: processing → ready या failed, साथ में error में कारण का टेक्स्ट।
आर्काइव को क्या पास करना होगा:
- यह सर्वर पैक हो: एक ही रैपर (
Server Files/और ऐसे ही) हटाने के बादmods/याplugins/रूट में हो। सर्वर पर क्लाइंट पैक खाली वर्ल्ड बनाता है, इसलिए हम उसे इंस्टॉल करने के बजाय अस्वीकार करते हैं; - आर्काइव के अंदर नामों में
.., एब्सोल्यूट पाथ या Windows सेपरेटर न हों; - न पासवर्ड, न कोई अनोखी कम्प्रेशन विधि (सिर्फ़ store और deflate);
- सीमाएँ: 60,000 फ़ाइलें, खोलने पर 12 GB, कम्प्रेशन अनुपात 200× तक।
फ़ेल होना प्रकाशित वर्शन को प्रभावित नहीं करता: आपके क्लाइंट पिछला वर्शन चलाते रहते हैं, और आप दोबारा अपलोड करते हैं। अधूरे ड्राफ़्ट: प्रति सर्वर सेटअप तीन से ज़्यादा नहीं, छोड़े गए ड्राफ़्ट एक दिन बाद अपने आप साफ़ हो जाते हैं।
प्रकाशन, रोलबैक और हटाना
| रिक्वेस्ट | यह क्या करती है |
|---|---|
POST .../versions/{label}/publish | वर्शन को प्रकाशित करें। रोलबैक भी इसी तरह होता है: पिछला वर्शन प्रकाशित करें — नए सर्वर उसे फिर से पाते हैं |
POST .../versions/{label}/archive-version | वर्शन को चयन से हटाएँ। जिनके पास यह पहले से है, उनके पास यह बना रहेगा |
PATCH .../versions/{label} | पहले से बने वर्शन का विवरण बदलें: changelog और minRamMb। वर्शन की फ़ाइलें अपरिवर्तनीय हैं, इसलिए कोर, लोडर और Java नहीं बदलते |
DELETE .../versions/{label} | वर्शन को उसकी फ़ाइलों समेत हटाएँ। प्रकाशित वर्शन या कम से कम एक सर्वर पर मौजूद वर्शन को हटाया नहीं जा सकता |
GET .../versions | चयन के लिए उपलब्ध वर्शन (सार्वजनिक, बिना टोकन) |
GET .../versions/all | आपके सब कुछ, ड्राफ़्ट और फ़ेल समेत |
GET .../versions/rollout | कितने सर्वर किस वर्शन पर हैं — आप देख सकते हैं कि अपडेट कैसे फैल रहा है |
प्रकाशन कोर, गेम वर्शन, लोडर पिन, Java और वर्शन की मेमोरी सीमा को सर्वर सेटअप कार्ड में डाल देता है: नए सर्वर आपकी ओर से किसी अतिरिक्त काम के बिना इसे पा लेते हैं।
सर्वर मालिक को क्या दिखता है
पैनल में, प्रीमियम सर्वर सेटअप ब्लॉक में: कौन-सा वर्शन इंस्टॉल है, कौन-सा जारी हुआ है, आपका changelog, और “Switch” बटन वाली वर्शन सूची। अपडेट वर्ल्ड को प्रभावित नहीं करता — सिर्फ़ सर्वर सेटअप की फ़ाइलें बदली जाती हैं, और बदलने से पहले हम एक कॉपी ले लेते हैं। कस्टम मॉड, अगर आपने इजाज़त दी है, तो स्विच करने के बाद दोबारा जोड़ने पड़ेंगे: सर्वर सेटअप एक पूरे के रूप में चलता है, और mods/ में पुराने वर्शन का आधा हिस्सा स्टार्टअप पर क्रैश कर देता है।
अगर मालिक का प्लान किसी वर्शन को नहीं संभाल सकता, तो हम उसे छिपाने के बजाय कारण के साथ दिखाते हैं: इंसान को दिखना चाहिए कि उसे क्या चाहिए, न कि अंदाज़ा लगाना चाहिए कि सर्वर सेटअप अपडेट क्यों नहीं हो रहा।
अपने सर्वर सेटअप का पेज
अपने सर्वर सेटअप का लैंडिंग पेज आप अपने अकाउंट में ख़ुद बनाते हैं (प्रोफ़ाइल → “My server setups” → “Server setup pages”): पहली स्क्रीन, फ़ीचर, स्क्रीनशॉट, सवाल-जवाब, आपके रंग। प्लान और वर्शन सूची हमारे डेटा से भरी जाती है ताकि वे पुरानी न पड़ें।
तैयार पेज millida.net/sborka/<your-address> पर रहता है — एक आम वेबसाइट पेज, जिसे सर्च इंजन इंडेक्स करते हैं और जो हमारे साइटमैप में शामिल होता है। ड्राफ़्ट आपके अलावा किसी को नहीं दिखता।
इमेज भी वहीं, आपके अकाउंट में अपलोड होती हैं: पेज हमारे डोमेन से सर्व होता है, और उसकी फ़ाइलें हमारे पास रखी जाती हैं — अगर आपकी होस्टिंग बंद हो जाए, तो पेज सुरक्षित रहता है।
पेज API से एडिट नहीं किए जा सकते: यह एक स्क्रीन है, रोलआउट नहीं।
रिस्पॉन्स कोड
| कोड | कब | क्या करें |
|---|---|---|
403 | ग़लत issuance टोकन | X-Pack-Token जाँचें। टोकन एक सर्वर सेटअप से बँधा होता है: यह किसी और की key के साथ काम नहीं करता |
404 | सर्वर सेटअप बंद है, issuance से जुड़ा नहीं है, या ऐसा कोई वर्शन नहीं है | हमें लिखें |
400 | expiresAt तारीख़ पार्स नहीं हो पाती, ग़लत वर्शन लेबल, खाली या बहुत बड़ा चंक | एरर टेक्स्ट देखें |
409 | वर्शन पहले ही बन चुका है, पार्स हो चुका है, प्रकाशित है, या सर्वर पर इंस्टॉल है | लेबल अपरिवर्तनीय हैं: अगला जारी करें |
429 | प्रति मिनट 30 से ज़्यादा रिक्वेस्ट (अपलोड — 600) | बैच में भेजें, और बड़े चंक भेजें |
बेचने से पहले सब कुछ कैसे टेस्ट करें
हमसे कुछ टेस्ट कोड माँगें: API से एक कोड जारी करें, उसे हमारी होस्टिंग पर अपने सर्वर पर एक्टिवेट करें, देखें कि वेबहुक में क्या आया और keys/status क्या दिखाता है। इस तरह आप पहले पेइंग कस्टमर के गुज़रने से पहले ख़रीदार का पूरा रास्ता देख लेंगे।
