SLA 99.9% uptime

गारंटीज़

अपटाइम गारंटीज़

अपटाइम की गणना कैलेंडर माह के दौरान https://api.astroway.info/v1/health से HTTP 200 स्थिति के साथ 1,000 मिलीसेकंड के भीतर की जाती है। नियोजित रखरखाव (कम से कम 48 घंटे पहले स्थिति पृष्ठ पर घोषित) की गणना में शामिल नहीं किया जाता।

लक्षित विलंब

api.astroway.info/v1/* पर एक क्षेत्र से मापा जाता है, केवल सर्वर गणना समय (क्लाइंट और नेटवर्क को छोड़कर)। पूर्ण त्रैमासिक रिपोर्ट स्थिति पृष्ठ पर प्रकाशित की जाती है।

मानक एंडपॉइंट

Chart, planets, synastry, transits, progressions, ACG, geodetic, solar-return और इसी तरह।

अस्वीकरण: वास्तविक संख्याएँ आंतरिक सैंपलिंग से हैं, जो api-calc की निगरानी से ली गई हैं। उत्पादन-टेलीमेट्री डैशबोर्ड रोडमैप में है। ध्यान दें: p99 = उच्चतम सीमाएँ, इसलिए समय p50 की तुलना में काफी अधिक है।

भारी एंडपॉइंट

बहु-दिवसीय समुच्चय: transit-calendar, forecast-calendar, moon-aspects, aspect-timeline, group-synastry, eclipse-analysis.

रेक्टिफिकेशन

POST /v1/rectification (120 से॰ तक) और POST /v1/rectification/trutine (15 से॰ तक) अपने स्वभाव से लंबे समय तक चलने वाले हैं और विलंब SLA के अधीन नहीं हैं। वे Request-Timeout हेडर का सम्मान करते हैं, जो 180 से॰ तक हो सकता है।

दर सीमित करना

rateLimitMiddleware में कुंजी पर नरम सीमित, HTTP 429 लौटाता है जिसमें Retry-After हेडर होता है।

सार्वजनिक सैंडबॉक्स (POST /v1/public/chart) IP द्वारा सीमित है — 30 अनुरोध / घंटा, बिना API कुंजी के।

अनुरोध पहचान

प्रत्येक प्रतिक्रिया में X-Request-Id हेडर (UUID) शामिल होता है। किसी घटना की रिपोर्ट करते समय इसे शामिल करें — हम 30 दिनों तक एक्सेस लॉग रखते हैं और केवल request-id से ही तुम्हारे कॉल को पूरी तरह से पुनर्निर्मित कर सकते हैं।

HTTP 5xx पर वही पहचानकर्ता प्रतिक्रिया निकाय में दोहराया जाता है:

{
  "ok": false,
  "error": {
    "code": "INTERNAL_ERROR",
    "message": "Internal server error",
    "request_id": "c07b5c55-7637-4add-bd2e-7c7c4deb365f"
  }
}

घटना प्रतिक्रिया

support@astroway.info पर request-id के साथ घटनाओं की रिपोर्ट करें। SEV-1 के लिए, स्थिति पृष्ठ भी देखें।

संस्करण नियंत्रण और deprecation

• एंडपॉइंट /v1/ के अंतर्गत रहते हैं और प्रमुख संस्करण के भीतर पीछे-संगत रहते हैं।
• breaking changes /v2/ के अंतर्गत जारी किए जाते हैं, और /v1/ कम से कम 12 महीने तक चलता रहता है।
• नए फ़ील्ड जोड़ना breaking नहीं माना जाता; ग्राहकों को अज्ञात फ़ील्ड को अनदेखा करना चाहिए।
• deprecation की घोषणा changelog पर की जाती है और ईमेल द्वारा खाताधारकों को कम से कम 90 दिन पहले भेजी जाती है।

समर्थन चैनल