POST/v1/catalog/resolve
नामों को कैटलॉग की सर्विसों से मिलाएँ
resolve_catalog_services
संगठन के डेटा में जैसा नाम दिखता है (ख़र्च की टेबल में सर्विस या वेंडर का नाम), उस हर नाम के लिए मेल खाने वाली कैटलॉग एंट्री लौटाता है या कुछ नहीं। मिलान नियत नियमों से होता है: नाम को सामान्य रूप में लाया जाता है (केस, डायक्रिटिक, विराम चिह्न, Inc, Ltd, GmbH जैसे क़ानूनी प्रत्यय) और नाम, ग्रुप, चुने हुए उपनामों और यूनीक वेबसाइट डोमेन से पूरा मिलाया जाता है। संगठन के अपने लिंक (/v1/org/service-aliases) को प्राथमिकता मिलती है। suggest: true के साथ बिना मेल वाले नामों को हाथ से लिंक करने के संकेत के रूप में पाँच तक मिलती-जुलती एंट्री मिलती हैं; ये कभी अपने आप लागू नहीं होतीं। Sursa जवाब की एंटिटी (AnswerEntity) और ख़र्च इनसाइट की पंक्तियों का service फ़ील्ड इसी तरह भरता है। एक रिक्वेस्ट में 200 नाम तक। यह पढ़ने वाला ऑपरेशन है और “View as” मोड में उपलब्ध है।
ऑथेंटिकेशन
Authorization हेडर में API कुंजी भेजें: Authorization: Bearer <कुंजी>।
हेडर पैरामीटर
X-View-Asstringसिर्फ़
adminरोल वाली API कुंजियों के लिए। रिक्वेस्ट को डेटा प्रोफ़ाइल<profile>[:viewer|verifier|editor]की ओर से चलाता है, जैसेemployee:viewer। इंस्टॉलेशन कुंजी इस हेडर का इस्तेमाल नहीं कर सकती (403)।
कुकी पैरामीटर
kb_view_asstringसेशन के लिए “View as” मोड की कुकी।
POST /auth/view-asइसे सेट करता है औरDELETE /auth/view-asहटाता है।
रिक्वेस्ट बॉडी
application/json
ऑब्जेक्ट: CatalogResolveRequest
namesarray of stringज़रूरीसंगठन के डेटा के नाम (1–200), जैसे वे टेबल और जवाबों में दिखते हैं।
items ≥ 1, items ≤ 200
suggestbooleanजिन नामों का मिलान नहीं हुआ, उनके लिए पाँच तक मिलती-जुलती एंट्री लौटाएँ (हाथ से जोड़ने के लिए संकेत)।
डिफ़ॉल्ट: false
रिस्पॉन्स
200सफल रिस्पॉन्स
रिस्पॉन्स हेडर
RateLimit-Policyलागू सीमाएँ, IETF ड्राफ़्ट
draft-ietf-httpapi-ratelimit-headersके फ़ॉर्मेट में: कॉमा से अलग आइटम"<name>";q=<quota>;w=<window in seconds>।keyAPI कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यहuserहै, बिना क्रेडेंशियल केip);minute,dayऔरmonthUTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।RateLimitRateLimit-Policyकी हर सीमा में से कितना बचा है:"<name>";r=<remaining>;t=<seconds until reset>।X-RateLimit-LimitRateLimit-Policyकी सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।X-RateLimit-Remainingसबसे सख़्त सीमा में बची रिक्वेस्ट।
X-RateLimit-Resetसबसे सख़्त सीमा के रीसेट होने तक के सेकंड।
401कोई क्रेडेंशियल नहीं भेजा गया (न सेशन कुकी, न API कुंजी), या कुंजी नहीं मिली।
रिस्पॉन्स हेडर
RateLimit-Policyलागू सीमाएँ, IETF ड्राफ़्ट
draft-ietf-httpapi-ratelimit-headersके फ़ॉर्मेट में: कॉमा से अलग आइटम"<name>";q=<quota>;w=<window in seconds>।keyAPI कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यहuserहै, बिना क्रेडेंशियल केip);minute,dayऔरmonthUTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।RateLimitRateLimit-Policyकी हर सीमा में से कितना बचा है:"<name>";r=<remaining>;t=<seconds until reset>।X-RateLimit-LimitRateLimit-Policyकी सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।X-RateLimit-Remainingसबसे सख़्त सीमा में बची रिक्वेस्ट।
X-RateLimit-Resetसबसे सख़्त सीमा के रीसेट होने तक के सेकंड।
application/json
403कार्रवाई की अनुमति नहीं है: रोल काफ़ी नहीं है, कलेक्शन या कार्ड तक ऐक्सेस नहीं है, रिक्वेस्ट “View as” मोड में चल रही है, या संगठन निलंबित है या हटा दिया गया है (`detail` एक ऑब्जेक्ट है, जिसमें `code: org_suspended | org_deleted` है)।
रिस्पॉन्स हेडर
RateLimit-Policyलागू सीमाएँ, IETF ड्राफ़्ट
draft-ietf-httpapi-ratelimit-headersके फ़ॉर्मेट में: कॉमा से अलग आइटम"<name>";q=<quota>;w=<window in seconds>।keyAPI कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यहuserहै, बिना क्रेडेंशियल केip);minute,dayऔरmonthUTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।RateLimitRateLimit-Policyकी हर सीमा में से कितना बचा है:"<name>";r=<remaining>;t=<seconds until reset>।X-RateLimit-LimitRateLimit-Policyकी सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।X-RateLimit-Remainingसबसे सख़्त सीमा में बची रिक्वेस्ट।
X-RateLimit-Resetसबसे सख़्त सीमा के रीसेट होने तक के सेकंड।
application/json
422वैलिडेशन एरर: बॉडी या पैरामीटर स्कीमा से मेल नहीं खाते (`detail` वैलिडेशन एरर की सूची है), या पैरामीटर का मान सीमा से बाहर है (`detail` एक संदेश है)।
रिस्पॉन्स हेडर
RateLimit-Policyलागू सीमाएँ, IETF ड्राफ़्ट
draft-ietf-httpapi-ratelimit-headersके फ़ॉर्मेट में: कॉमा से अलग आइटम"<name>";q=<quota>;w=<window in seconds>।keyAPI कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यहuserहै, बिना क्रेडेंशियल केip);minute,dayऔरmonthUTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।RateLimitRateLimit-Policyकी हर सीमा में से कितना बचा है:"<name>";r=<remaining>;t=<seconds until reset>।X-RateLimit-LimitRateLimit-Policyकी सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।X-RateLimit-Remainingसबसे सख़्त सीमा में बची रिक्वेस्ट।
X-RateLimit-Resetसबसे सख़्त सीमा के रीसेट होने तक के सेकंड।
application/json
429बहुत ज़्यादा रिक्वेस्ट (`api.rate_limited`), संगठन का मिनट, दिन या महीने का कोटा ख़त्म हो गया है (`api.quota_exceeded`; `error.details` में `quota`, `limit` और `reset_at` होते हैं), संगठन की सीमा पूरी हो गई है, या जवाब देने वाली सर्विस व्यस्त है (`answers.engine_busy`)। `Retry-After` हेडर में दिए गए समय तक इंतज़ार करें।
रिस्पॉन्स हेडर
Retry-Afterरिक्वेस्ट का रीट्राई करने से पहले कितने सेकंड इंतज़ार करना है।
RateLimit-Policyलागू सीमाएँ, IETF ड्राफ़्ट
draft-ietf-httpapi-ratelimit-headersके फ़ॉर्मेट में: कॉमा से अलग आइटम"<name>";q=<quota>;w=<window in seconds>।keyAPI कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यहuserहै, बिना क्रेडेंशियल केip);minute,dayऔरmonthUTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।RateLimitRateLimit-Policyकी हर सीमा में से कितना बचा है:"<name>";r=<remaining>;t=<seconds until reset>।X-RateLimit-LimitRateLimit-Policyकी सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।X-RateLimit-Remainingसबसे सख़्त सीमा में बची रिक्वेस्ट।
X-RateLimit-Resetसबसे सख़्त सीमा के रीसेट होने तक के सेकंड।
application/json
एरर कोड
हर रिक्वेस्ट के सामान्य कोड के अलावा वे कोड, जो यह एंडपॉइंट एरर होने पर error.code में लौटा सकता है।
सुरक्षित रीट्राई
हर POST और PATCH के साथ Idempotency-Key हेडर भेजें (उदाहरण के लिए, UUID)। 24 घंटे के अंदर उसी कुंजी के साथ रीट्राई करने पर रिक्वेस्ट दोबारा नहीं चलती, बल्कि सेव किया गया रिस्पॉन्स लौटता है।
रेट लिमिट
रिस्पॉन्स में RateLimit और RateLimit-Policy हेडर होते हैं, और पहले वाले X-RateLimit-Limit, X-RateLimit-Remaining और X-RateLimit-Reset भी। 429 रिस्पॉन्स में Retry-After सेकंड में होता है: उतना इंतज़ार करें और रीट्राई करें।