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

POST/v1/uploads/{upload_id}/complete

अपलोड पूरा करें

complete_upload

जब सभी हिस्से मिल जाते हैं, Sursa फ़ाइल जोड़ता है, पूरी फ़ाइल के SHA-256 की तुलना बॉडी के sha256 से करता है और वही जाँचें चलाता है, जो एक रिक्वेस्ट वाले अपलोड के लिए होती हैं: कंटेंट के सिग्नेचर से फ़ॉर्मेट और एंटीवायरस स्कैनिंग। नतीजा ready होता है, या reject_reason के साथ rejected (checksum_mismatch, type_mismatch, unsupported_format, infected, scan_unavailable, unsafe_content)। फ़ॉर्मेट या एंटीवायरस जाँच से हुई हर अस्वीकृति ऑडिट लॉग में file.rejected के रूप में दर्ज होती है।

200 रिस्पॉन्स का मतलब है कि नतीजा तैयार है; 202 का मतलब है कि फ़ाइल अभी जाँची जा रही है (processing), और नतीजा GET /v1/uploads/{upload_id} से मिलता है। अगर स्टेटस pending पर लौट आए (API इंस्टेंस के रीस्टार्ट ने जाँच रोक दी), तो complete फिर से भेजें। नतीजे के बाद complete दोहराने पर वही नतीजा लौटता है। छूटे हुए हिस्से 409 uploads.incomplete लौटाते हैं (details.missing)। बनाते समय बताए गए से अलग sha256, या मिले हुए हिस्से से अलग parts[].etag, 422 uploads.checksum_mismatch लौटाता है। तैयार अपलोड, जो इस्तेमाल नहीं हुआ, 24 घंटे तक रहता है। 1.62.0 में जोड़ा गया।

ऑथेंटिकेशन

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

पाथ पैरामीटर

  • upload_idstringज़रूरी

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

    length ≤ 64

हेडर पैरामीटर

  • Idempotency-Keystring

    लिखने वाली रिक्वेस्ट के सुरक्षित रीट्राई के लिए कुंजी: 1 से 255 प्रिंट होने वाले ASCII कैरेक्टर; हर लॉजिकल ऑपरेशन के लिए एक UUID v4 की सलाह दी जाती है। उसी कुंजी के साथ 24 घंटे के अंदर रीट्राई ऑपरेशन को दोबारा नहीं चलाता: वह सेव किया गया रिस्पॉन्स (स्टेटस, हेडर और बॉडी) Idempotency-Replayed: true हेडर के साथ लौटाता है। वही कुंजी, पर अलग मेथड, पाथ, Content-Type या बॉडी हो, तो 409 api.idempotency_mismatch लौटता है; जब तक पहली रिक्वेस्ट चल रही है, तब तक 409 api.idempotency_in_progress और Retry-After: 1। 5xx या 429 रिस्पॉन्स के बाद कुंजी छोड़ दी जाती है, और रीट्राई ऑपरेशन को फिर से चलाता है। कुंजी संगठन और कॉल करने वाले (API कुंजी, यूज़र या कस्टम स्रोत की कुंजी) के दायरे में होती है।

    length ≥ 1, length ≤ 255

रिक्वेस्ट बॉडी

application/json

ऑब्जेक्ट: UploadComplete

  • sha256stringज़रूरी

    पूरी फ़ाइल का SHA-256।

  • partsarray of UploadPartRef

    हिस्सों की वैकल्पिक जाँच: हर हिस्से का ETag, जैसा PUT …/parts/{n} ने लौटाया था।

    items ≤ 1000

रिस्पॉन्स

200नतीजा तैयार है: `ready` या `rejected`।

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

  • 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

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

  • Idempotency-Replayed

    true का मतलब है कि रिस्पॉन्स इस Idempotency-Key के लिए सेव किए गए रिस्पॉन्स से दोहराया गया: ऑपरेशन दोबारा नहीं चला।

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ज़रूरी

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

202फ़ाइल अभी जाँची जा रही है (`processing`)।

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

  • 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

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

  • Idempotency-Replayed

    true का मतलब है कि रिस्पॉन्स इस Idempotency-Key के लिए सेव किए गए रिस्पॉन्स से दोहराया गया: ऑपरेशन दोबारा नहीं चला।

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

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

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

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

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

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

409ऑब्जेक्ट की स्थिति यह कार्रवाई करने नहीं देती, जैसे डुप्लिकेट, चल रही इंडेक्सिंग या पहले से प्रोसेस हो चुका जॉब।

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

  • 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

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

410ऑब्जेक्ट मौजूद था, पर अब उपलब्ध नहीं है: लिंक इस्तेमाल हो चुका है या उसकी मियाद ख़त्म हो गई है, या रखने की अवधि ख़त्म होने पर फ़ाइल हटा दी गई है।

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

  • 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

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

422वैलिडेशन एरर: बॉडी या पैरामीटर स्कीमा से मेल नहीं खाते (`detail` वैलिडेशन एरर की सूची है), या पैरामीटर का मान सीमा से बाहर है (`detail` एक संदेश है)।

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

  • 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

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

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

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

एरर कोड

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

सुरक्षित रीट्राई

हर POST और PATCH के साथ Idempotency-Key हेडर भेजें (उदाहरण के लिए, UUID)। 24 घंटे के अंदर उसी कुंजी के साथ रीट्राई करने पर रिक्वेस्ट दोबारा नहीं चलती, बल्कि सेव किया गया रिस्पॉन्स लौटता है।

रेट लिमिट

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

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