मुख्य कंटेंट पर जाएँ
Sursa Developers

GET/v1/uploads/{upload_id}

अपलोड पाएँ

get_upload

अपलोड का स्टेटस और मिले हुए हिस्से (parts: हर हिस्से का नंबर, आकार, SHA-256 और ETag) लौटाता है, ताकि कनेक्शन टूटने के बाद क्लाइंट सिर्फ़ छूटे हुए हिस्से भेजे। status: pending हिस्सों और complete का इंतज़ार करता है, processing का मतलब है कि फ़ाइल जोड़ी और जाँची जा रही है, ready का मतलब है कि उसे इस्तेमाल किया जा सकता है, rejected का मतलब है कि उसे अस्वीकार किया गया (reject_reason), consumed का मतलब है कि वह पहले ही इस्तेमाल हो चुका है, और expired का मतलब है कि उसका समय ख़त्म हो गया। किसी दूसरे कॉल करने वाले का अपलोड 404 uploads.not_found लौटाता है। 1.62.0 में जोड़ा गया।

ऑथेंटिकेशन

Authorization हेडर में API कुंजी भेजें: Authorization: Bearer <कुंजी>।

पाथ पैरामीटर

  • upload_idstringज़रूरी

    अपलोड का ID (upl_ और उसके बाद 32 hex कैरेक्टर)।

    length ≤ 64

रिस्पॉन्स

200सफल रिस्पॉन्स

रिस्पॉन्स हेडर

  • RateLimit-Policy

    लागू सीमाएँ, IETF ड्राफ़्ट draft-ietf-httpapi-ratelimit-headers के फ़ॉर्मेट में: कॉमा से अलग आइटम "<name>";q=<quota>;w=<window in seconds>। key API कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यह user है, बिना क्रेडेंशियल के ip); minute, day और month UTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।

  • RateLimit

    RateLimit-Policy की हर सीमा में से कितना बचा है: "<name>";r=<remaining>;t=<seconds until reset>।

  • X-RateLimit-Limit

    RateLimit-Policy की सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।

  • X-RateLimit-Remaining

    सबसे सख़्त सीमा में बची रिक्वेस्ट।

  • X-RateLimit-Reset

    सबसे सख़्त सीमा के रीसेट होने तक के सेकंड।

application/json

ऑब्जेक्ट: Upload

  • idstringज़रूरी

    अपलोड का ID (upl_ और उसके बाद 32 hex अक्षर)।

  • purposeUploadPurposeज़रूरी
  • filenamestringज़रूरी

    फ़ाइल का नाम (फ़ोल्डर के बिना)।

  • content_typestringज़रूरी

    घोषित कंटेंट टाइप; घोषित न हो, तो ख़ाली।

  • sizeinteger (int64)ज़रूरी

    फ़ाइल का आकार, बाइट में।

  • sha256string | nullज़रूरी

    फ़ाइल का SHA-256, जो बनाते समय या complete के समय घोषित किया गया; अभी पता न हो, तो null।

  • statusUploadStatusज़रूरी
  • part_sizeinteger (int64)ज़रूरी

    आख़िरी हिस्से को छोड़कर हर हिस्से का आकार (5 से 100 MiB तक)।

  • part_countintegerज़रूरी

    हिस्सों की संख्या।

    ≥ 1, ≤ 1000

  • parts_receivedintegerज़रूरी

    मिले हुए हिस्सों की संख्या।

    ≥ 0

  • partsarray of UploadPartज़रूरी

    मिले हुए हिस्से, नंबर के अनुसार (POST /v1/uploads के रिस्पॉन्स में ख़ाली)।

  • reject_reasonstring | nullज़रूरी

    अस्वीकार करने का कारण (rejected): checksum_mismatch, type_mismatch, unsupported_format, infected, scan_unavailable, unsafe_content। यह सूची बढ़ सकती है; अस्वीकार न हुआ हो, तो null।

  • reject_detailsobject | nullज़रूरी

    अस्वीकार करने का ब्योरा (एक्सटेंशन, घोषित और पहचाना गया फ़ॉर्मेट, चेकसम); अस्वीकार न हुआ हो, तो null।

  • created_atstring (date-time)ज़रूरी

    अपलोड कब बनाया गया।

  • expires_atstring (date-time)ज़रूरी

    अपलोड पूरा करने की और, तैयार होने के बाद, उसे इस्तेमाल करने की समय-सीमा।

  • completed_atstring (date-time) | nullज़रूरी

    जाँच कब पूरी हुई (ready या rejected)।

  • consumed_atstring (date-time) | nullज़रूरी

    अपलोड कब इस्तेमाल हुआ (कार्ड, आर्काइव या इम्पोर्ट में)।

401कोई क्रेडेंशियल नहीं भेजा गया (न सेशन कुकी, न API कुंजी), या कुंजी नहीं मिली।

रिस्पॉन्स हेडर

  • RateLimit-Policy

    लागू सीमाएँ, IETF ड्राफ़्ट draft-ietf-httpapi-ratelimit-headers के फ़ॉर्मेट में: कॉमा से अलग आइटम "<name>";q=<quota>;w=<window in seconds>। key API कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यह user है, बिना क्रेडेंशियल के ip); minute, day और month UTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।

  • RateLimit

    RateLimit-Policy की हर सीमा में से कितना बचा है: "<name>";r=<remaining>;t=<seconds until reset>।

  • X-RateLimit-Limit

    RateLimit-Policy की सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।

  • X-RateLimit-Remaining

    सबसे सख़्त सीमा में बची रिक्वेस्ट।

  • X-RateLimit-Reset

    सबसे सख़्त सीमा के रीसेट होने तक के सेकंड।

application/json

ऑब्जेक्ट: Error

403कार्रवाई की अनुमति नहीं है: रोल काफ़ी नहीं है, कलेक्शन या कार्ड तक ऐक्सेस नहीं है, रिक्वेस्ट “View as” मोड में चल रही है, या संगठन निलंबित है या हटा दिया गया है (`detail` एक ऑब्जेक्ट है, जिसमें `code: org_suspended | org_deleted` है)।

रिस्पॉन्स हेडर

  • RateLimit-Policy

    लागू सीमाएँ, IETF ड्राफ़्ट draft-ietf-httpapi-ratelimit-headers के फ़ॉर्मेट में: कॉमा से अलग आइटम "<name>";q=<quota>;w=<window in seconds>। key API कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यह user है, बिना क्रेडेंशियल के ip); minute, day और month UTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।

  • RateLimit

    RateLimit-Policy की हर सीमा में से कितना बचा है: "<name>";r=<remaining>;t=<seconds until reset>।

  • X-RateLimit-Limit

    RateLimit-Policy की सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।

  • X-RateLimit-Remaining

    सबसे सख़्त सीमा में बची रिक्वेस्ट।

  • X-RateLimit-Reset

    सबसे सख़्त सीमा के रीसेट होने तक के सेकंड।

application/json

ऑब्जेक्ट: Error

404ऑब्जेक्ट मौजूद नहीं है या आपके लिए उपलब्ध नहीं है। API यह पुष्टि नहीं करता कि प्रतिबंधित ऑब्जेक्ट मौजूद है।

रिस्पॉन्स हेडर

  • RateLimit-Policy

    लागू सीमाएँ, IETF ड्राफ़्ट draft-ietf-httpapi-ratelimit-headers के फ़ॉर्मेट में: कॉमा से अलग आइटम "<name>";q=<quota>;w=<window in seconds>। key API कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यह user है, बिना क्रेडेंशियल के ip); minute, day और month UTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।

  • RateLimit

    RateLimit-Policy की हर सीमा में से कितना बचा है: "<name>";r=<remaining>;t=<seconds until reset>।

  • X-RateLimit-Limit

    RateLimit-Policy की सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।

  • X-RateLimit-Remaining

    सबसे सख़्त सीमा में बची रिक्वेस्ट।

  • X-RateLimit-Reset

    सबसे सख़्त सीमा के रीसेट होने तक के सेकंड।

application/json

ऑब्जेक्ट: Error

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>। key API कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यह user है, बिना क्रेडेंशियल के ip); minute, day और month UTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।

  • RateLimit

    RateLimit-Policy की हर सीमा में से कितना बचा है: "<name>";r=<remaining>;t=<seconds until reset>।

  • X-RateLimit-Limit

    RateLimit-Policy की सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।

  • X-RateLimit-Remaining

    सबसे सख़्त सीमा में बची रिक्वेस्ट।

  • X-RateLimit-Reset

    सबसे सख़्त सीमा के रीसेट होने तक के सेकंड।

application/json

ऑब्जेक्ट: Error

एरर कोड

हर रिक्वेस्ट के सामान्य कोड के अलावा वे कोड, जो यह एंडपॉइंट एरर होने पर error.code में लौटा सकता है।

रेट लिमिट

रिस्पॉन्स में RateLimit और RateLimit-Policy हेडर होते हैं, और पहले वाले X-RateLimit-Limit, X-RateLimit-Remaining और X-RateLimit-Reset भी। 429 रिस्पॉन्स में Retry-After सेकंड में होता है: उतना इंतज़ार करें और रीट्राई करें।

← uploads · API रेफ़रेंस