YouTube Content ID API - बदलाव का इतिहास

ध्यान दें: YouTube Content ID API का इस्तेमाल, YouTube के कॉन्टेंट पार्टनर ही कर सकते हैं. यह सभी डेवलपर या YouTube के सभी उपयोगकर्ताओं के लिए उपलब्ध नहीं है. अगर आपको Google API कंसोल में दी गई सेवाओं में, YouTube Content ID API नहीं दिखता है, तो YouTube Partner Program के बारे में ज़्यादा जानने के लिए, YouTube सहायता केंद्र पर जाएं.

इस पेज पर, YouTube Content ID API में हुए बदलावों और दस्तावेज़ से जुड़े अपडेट की जानकारी दी गई है.

26 मार्च, 2025

YouTube 31 मार्च, 2025 से, शॉर्ट वीडियो पर मिले व्यू की गिनती करने का तरीका बदल देगा. पहले, शॉर्ट वीडियो को कुछ सेकंड तक चलाने के बाद ही उसे व्यू के तौर पर गिना जाता था. अब शॉर्ट वीडियो के व्यू की गिनती इस आधार पर की जाएगी कि आपका कोई शॉर्ट वीडियो कितनी बार चलाया गया है या उसे फिर से देखने के लिए कितनी बार चलाया गया है. इस पर वीडियो देखने के कम से कम समय से जुड़ी कोई शर्त लागू नहीं होगी. ज़्यादा जानें

इस बदलाव के मुताबिक, Content ID API को 30 जून, 2025 तक इन तरीकों से अपडेट किया जाएगा:

  • claimSearch.list.sort के लिए, क्रम से लगाने के क्रम अपडेट हो जाएंगे:
    • DAILY_ENGAGED_VIEWS को व्यू की गिनती करने के पुराने तरीके के आधार पर, रोज़ाना मिलने वाले व्यू की संख्या में जोड़ा जाएगा.
    • LIFETIME_ENGAGED_VIEWS को व्यू की गिनती करने के पुराने तरीके के आधार पर, लाइफ़टाइम व्यू की संख्या में जोड़ दिया जाएगा.
  • assetSearch.list.sort के लिए, क्रम से लगाने के क्रम अपडेट हो जाएंगे:
    • DAILY_ENGAGED_VIEWS को व्यू की गिनती करने के पुराने तरीके के आधार पर, रोज़ाना मिलने वाले व्यू की संख्या में जोड़ा जाएगा.

इस बदलाव के मुताबिक, Content ID API को 30 सितंबर, 2025 तक इन तरीकों से अपडेट किया जाएगा:

  • assetSearch.list.sort क्रम से लगाने का तरीका VIEWS बंद कर दिया जाएगा.
  • claimSearch.list.sort क्रम से लगाने का तरीका VIEW_COUNT बंद कर दिया जाएगा.
  • claimSearch.claimSnippet.videoViews को अपडेट किया जाएगा, ताकि शॉर्ट वीडियो को मिले व्यू की गिनती करने के नए तरीके को दिखाया जा सके.
  • व्यू की गिनती करने के पुराने तरीके के आधार पर, claimSearch.claimSnippet.engagedViews को व्यू की संख्या में जोड़ दिया जाएगा

14 जनवरी, 2025

videoAdvertisingOption रिसॉर्स के autoGeneratedBreaks[] फ़ील्ड को अपडेट कर दिया गया है. अब हम ad_breaks और autoGeneratedBreaks को एक ही समय पर उपलब्ध कराने की अनुमति देते हैं. अगर किसी वीडियो में adBreaks तय है और autoGeneratedBreaks को 'सही' पर सेट किया गया है, तो हमारे सिस्टम मैन्युअल तरीके से तय किए गए विज्ञापन स्लॉट के अलावा, विज्ञापन दिखाने के लिए जगहों की पहचान करेंगे. ज़्यादा जानकारी के लिए, सहायता लेख देखें.

10 नवंबर, 2023

videoAdvertisingOption रिसॉर्स के adFormats[] फ़ील्ड को अपडेट कर दिया गया है, ताकि उस फ़ील्ड के लिए सिर्फ़ third_party मान्य वैल्यू हो. इन विज्ञापन फ़ॉर्मैट का इस्तेमाल अब नहीं किया जा सकता: instream_trueview, instream_standard, display, preroll, postroll. ज़्यादा जानकारी के लिए, सहायता लेख देखें.

1 जून, 2023

ध्यान दें: यह, हटाए गए टैग और एट्रिब्यूट से जुड़ी सूचना है.

इस अपडेट में ये बदलाव शामिल हैं:

  • मौजूदा रिसॉर्स और तरीकों में होने वाले अपडेट

    • videoAdvertisingOption रिसॉर्स के breakPosition[] फ़ील्ड को 'इस्तेमाल नहीं किया जा सकता' के तौर पर मार्क कर दिया गया है. इसे साल 2024 में हटा दिया जाएगा.
      videoAdvertisingOptions.update और videoAdvertisingOptions.patch तरीके पहले से ही फ़ील्ड को अनदेखा करते हैं.
    • videoAdvertisingOption संसाधन का अब इस्तेमाल नहीं किया जाने वाला adBreaks[].slot[] फ़ील्ड हटा दिया गया है.
    • asset संसाधन के इस्तेमाल पर रोक लगाए गए category और showCustomId फ़ील्ड हटा दिए गए हैं.
    • नए claim रिसॉर्स के timeStatusLastModified फ़ील्ड से पता चलता है कि दावे में पिछली बार कब बदलाव किया गया था.
    • claimSearch.list वाले नए तरीके के isVideoShortsEligible पैरामीटर का इस्तेमाल करके, दावा किए गए वीडियो को YouTube Shorts पर अपलोड करने की ज़रूरी शर्तों के हिसाब से फ़िल्टर किया जा सकता है.

  • नए संसाधन और तरीके

    • एपीआई अब YouTube Music के संसाधनों को सूची में शामिल करने की सुविधा देता है:

20 दिसंबर, 2022

assetSearch.list तरीके के ownershipRestrictionक्वेरी पैरामीटर की परिभाषा को अपडेट किया गया है, ताकि यह साफ़ तौर पर बताया जा सके कि अगर उस पैरामीटर की वैल्यू none है, तो metadataSearchFields पैरामीटर की वैल्यू में कम से कम एक आईडी फ़िल्टर का इस्तेमाल करना ज़रूरी है. दस्तावेज़ में किए गए इस बदलाव से, एपीआई के काम करने के तरीके में कोई बदलाव नहीं होता.

9 नवंबर, 2022

asset.get और asset.list तरीकों के दस्तावेज़ों को अपडेट किया गया है, ताकि यह बताया जा सके कि इनके लिए एक से ज़्यादा वैल्यू कैसे काम करती हैं:

28 सितंबर, 2022

asset resource में, लाइसेंस देने की सुविधा से जुड़ी जानकारी जोड़ी गई है.

18 जुलाई, 2022

claimSearch.list तरीके के inactiveReasons के दस्तावेज़ को अपडेट किया गया है, ताकि YouTube Studio के साथ काम करने के तरीके में सुधार किया जा सके:

  • Studio ने पहले ही Audio Swap और Song Erase के लिए सहायता हटा दी थी. इससे जुड़ी एपीआई वैल्यू, audio_removed और song_erased को चुपचाप अनदेखा कर दिया गया था और अब उन्हें दस्तावेज़ में शामिल नहीं किया गया है.
  • channel_whitelisted को channel_allowlisted से बदल दिया गया है. पिछली वैल्यू अब दस्तावेज़ में शामिल नहीं है, लेकिन इसे अब भी इस्तेमाल किया जा सकता है.
  • अब closed_disabled_monetization, closed_manually, closed_no_adsense, closed_own_video_match, reference_removed, replaced, और video_modified वैल्यू इस्तेमाल की जा सकती हैं.

14 जून, 2022

assetSearch संसाधन के दस्तावेज़ को अपडेट किया गया है, ताकि दो नई प्रॉपर्टी दिखें: isrcs[] और iswcs[]. नई isrcs[] और iswcs[] प्रॉपर्टी वैल्यू में, स्ट्रिंग की वैल्यू का एक कलेक्शन होता है. हर वैल्यू में, ISRC या ISWC की जानकारी होती है. यह जानकारी, खोज के नतीजे में दिखने वाली ऐसेट से मैप होती है.

assetSearch संसाधनों में पहले से शामिल isrc और iswc प्रॉपर्टी के बजाय, नई प्रॉपर्टी का सुझाव दिया जाता है, क्योंकि नई प्रॉपर्टी ज़्यादा सटीक डेटा देती हैं. नई प्रॉपर्टी में स्ट्रिंग वैल्यू की सूची हो सकती है. वहीं, isrc और iswc प्रॉपर्टी में, खोज के नतीजे से जुड़े सिर्फ़ एक आईएसआरसी या आईएसडब्ल्यूसी कोड की पहचान की जाती है.

12 मई, 2022

क्लाइंट लाइब्रेरी के लिंक को अपडेट किया गया है, ताकि वे Google APIs की स्टैंडर्ड क्लाइंट लाइब्रेरी पर ले जाएं. PHP के लिए पहले से जनरेट की गई बाइंडिंग अपडेट की गईं.

3 मई, 2022

claimSearch.list तरीके के status पैरामीटर में, अब संभावित दावे की जानकारी के आधार पर ज़्यादा फ़िल्टर इस्तेमाल किए जा सकते हैं.

May 2, 2022

assetSearch.list तरीके के जवाब के दस्तावेज़ को अपडेट किया गया है, ताकि AIP-158 के साथ लगातार सुधार किया जा सके:

  • pageInfo.totalResults के ब्यौरे में साफ़ तौर पर बताया गया है कि वैल्यू एक अनुमान है, न कि असल वैल्यू
  • pageInfo.resultsPerPage और pageInfo.startIndex फ़ील्ड हटा दिए गए हैं

25 अप्रैल, 2022

assetLabels.list संसाधन के दस्तावेज़ को अपडेट किया गया है, ताकि labelPrefix और q अनुरोध पैरामीटर का मतलब साफ़ तौर पर बताया जा सके. साथ ही, यह भी बताया जा सके कि अनुरोध / जवाब में पेजेशन की सुविधा काम करती है.

8 दिसंबर, 2021

claimSearch.list संसाधन के दस्तावेज़ को अपडेट किया गया है, ताकि इस तरीके के इस्तेमाल के दो उदाहरणों को सही तरीके से दिखाया जा सके:

  • आईडी (एसेट, पहचान फ़ाइल या वीडियो) या क्वेरी स्ट्रिंग के हिसाब से खोजें
  • दावे को बनाने की तारीख, उसमें बदलाव करने की तारीख या स्थिति के हिसाब से खोजना

इस्तेमाल के हर उदाहरण में, क्वेरी पैरामीटर का अलग सेट काम करता है. claimSearch.list तरीके के दस्तावेज़ को अपडेट किया गया है, ताकि यह बताया जा सके कि इस्तेमाल के अलग-अलग तरीकों के लिए कौनसे पैरामीटर काम करते हैं.

17 नवंबर, 2021

इस अपडेट में ये बदलाव शामिल हैं:

  • claims.update तरीके से, अब किसी इनऐक्टिव या संभावित दावे का स्टेटस active पर अपडेट किया जा सकता है. claim रिसॉर्स की status प्रॉपर्टी की परिभाषा से ज़्यादा जानकारी मिलती है.
  • claim और claimSearch संसाधनों के दस्तावेज़ को अपडेट किया गया है, ताकि नए studioInfo ऑब्जेक्ट को जोड़ा जा सके. इसमें दावे से जुड़े YouTube Studio पेजों के लिंक शामिल हैं.
  • claimSearch.list तरीके के origin पैरामीटर के लिए इस्तेमाल की जा सकने वाली वैल्यू की सूची बदल गई है. पैरामीटर में अब चार और वैल्यू इस्तेमाल की जा सकती हैं: batchTool, inProductShorts, melodyMatch, और youTubeAdmin. इसके अलावा, dropboxUpload और webUpload वैल्यू अब काम नहीं करती हैं.

26 फ़रवरी, 2021

claimSearch.list तरीके के videoId पैरामीटर के दस्तावेज़ को अपडेट किया गया है. इसमें बताया गया है कि पैरामीटर की वैल्यू में अब कॉमा लगाकर ज़्यादा से ज़्यादा 10 वीडियो आईडी डाले जा सकते हैं. अगर वैल्यू में 10 से ज़्यादा वीडियो आईडी शामिल हैं, तो एपीआई badRequest गड़बड़ी — 400 एचटीटीपी रिस्पॉन्स कोड दिखाएगा.

6 दिसंबर, 2018

ध्यान दें: यह, हटाए गए टैग और एट्रिब्यूट से जुड़ी सूचना है.

contentOwnerAdvertisingOptions संसाधन और उसके तरीकों के रेफ़रंस हटाने के लिए, एपीआई दस्तावेज़ को अपडेट कर दिया गया है. इन तरीकों का बहुत कम इस्तेमाल किया गया था. साथ ही, इस एलान से पहले, इनका इस्तेमाल करने वाले एपीआई उपयोगकर्ताओं से अलग से संपर्क किया गया था.

21 मार्च, 2018

इस अपडेट में ये बदलाव किए गए हैं:

  • अब जब भी कोई म्यूज़िक वीडियो या साउंड रिकॉर्डिंग ऐसेट शामिल, अपडेट या पैच की जाती है, तो metadataMine.artist प्रॉपर्टी को सेट करना ज़रूरी है. अगर उन रिसॉर्स टाइप के लिए प्रॉपर्टी सेट नहीं है, तो एपीआई अब गड़बड़ी का मैसेज दिखाता है. इसके अलावा, ध्यान दें कि metadataMine.artist प्रॉपर्टी का इस्तेमाल सिर्फ़ संगीत वीडियो और साउंड रिकॉर्डिंग के कलाकारों के लिए किया जा सकता है.

24 जुलाई, 2017

इस अपडेट में ये बदलाव किए गए हैं:

  • नया package रिसॉर्स, वेब, एसएफ़टीपी या डिलीवरी के किसी अन्य तरीके से डिलीवर की गई फ़ाइलों के ग्रुप को दिखाता है. इस संसाधन के लिए, एपीआई के दो तरीके काम करते हैं:

    • package.insert तरीका, सिर्फ़ मेटाडेटा वाले पैकेज की पुष्टि करता है और उसे अपलोड करता है. इस पैकेज में सिर्फ़ एक मेटाडेटा फ़ाइल होती है.
    • package.get फ़ंक्शन, पहले अपलोड किए गए पैकेज की जानकारी वापस लाता है.

  • validator.validate तरीके के लिए, uploaderName प्रॉपर्टी की परिभाषा को अपडेट किया गया है. इससे यह पता चलता है कि वैल्यू, डेटा अपलोड करने वाले कॉन्टेंट पार्टनर की पहचान नहीं करती. इसके बजाय, web-google या yt-google जैसी वैल्यू से उस अपलोड करने वाले खाते की पहचान होती है जिसका इस्तेमाल कॉन्टेंट का मालिक कर रहा है.

  • reference रिसॉर्स की status प्रॉपर्टी अब duplicate_on_hold वैल्यू का इस्तेमाल नहीं करती, ताकि यह पता चल सके कि कोई रेफ़रंस किसी दूसरे रेफ़रंस का डुप्लीकेट है. इसके बजाय, अगर कोई रेफ़रंस डुप्लीकेट है, तो status प्रॉपर्टी की वैल्यू अब inactive पर सेट हो जाती है और statusReason प्रॉपर्टी की वैल्यू REASON_DUPLICATE_FOR_OWNERS हो जाती है.

    हालांकि, पहले की तरह ही, रिसॉर्स की duplicateLeader प्रॉपर्टी सिर्फ़ तब पॉप्युलेट होती है, जब रेफ़रंस डुप्लीकेट हो. अगर यह सेट है, तो उस प्रॉपर्टी की वैल्यू से डुप्लीकेट रेफ़रंस की पहचान होती है.

17 अप्रैल, 2017

इस अपडेट में ये बदलाव किए गए हैं:

  • नया assetShare रिसॉर्स, सिर्फ़ कंपोज़िशन ऐसेट के लिए काम आता है. इससे, ऐसेट रिसॉर्स के दो रिप्रज़ेंटेशन के बीच के संबंध की पहचान की जाती है. इन इमेज में, डेटा पब्लिश करने का नया मॉडल दिखाया गया है. इसे इस तरह से डिज़ाइन किया गया है कि साउंड रिकॉर्डिंग ऐसेट से जुड़े आपके अधिकारों के बारे में ज़्यादा जानकारी मिल सके और उन पर बेहतर कंट्रोल किया जा सके.

    नए मॉडल में, हर साउंड रिकॉर्डिंग को सिर्फ़ एक यूनीक ऐसेट से मैप किया जाता है. इसे कंपोज़िशन व्यू कहा जाता है. उस ऐसेट का मेटाडेटा, जानकारी के कैननिकल सेट को दिखाता है. YouTube, किसी रिकॉर्डिंग से जुड़े कंपोज़िशन के अधिकारों के बारे में जानकारी दिखाता है. यह कई डेटा प्रोवाइडर से जानकारी इकट्ठा कर सकता है.

    इसके अलावा, कंपोज़िशन के हर मालिक के पास अपनी कंपोज़िशन शेयर ऐसेट होती है. कंपोज़िशन शेयर से उस जानकारी के बारे में पता चलता है जो किसी पब्लिशर ने कंपोज़िशन एसेट के लिए दी है. कंपोज़िशन शेयर को कई साउंड रिकॉर्डिंग से जोड़ा जा सकता है.

    assetShare रिसॉर्स, कॉम्पोज़िशन व्यू और कॉम्पोज़िशन शेयर के बीच के संबंध की पहचान करता है. assetShares.list के नए तरीके से, इनमें से कोई एक काम किया जा सकता है:

    • कंपोज़िशन व्यू का आईडी दें और उससे जुड़ा कंपोज़िशन शेयर वापस पाएं. अगर ऐसा शेयर मौजूद है, तो उसे पाने की अनुमति देने वाले पार्टनर के पास उसका मालिकाना हक होना चाहिए.
    • कॉन्टेंट पार्टनर के मालिकाना हक वाले कंपोज़िशन शेयर का आईडी दें और उन सभी कंपोज़िशन व्यू की सूची पाएं जिनसे वह शेयर लिंक है.

  • कंपोज़िशन ऐसेट मैनेज करना गाइड में बताया गया है कि एपीआई के अलग-अलग तरीके, अनुरोधों को कैसे मैनेज करते हैं. यह इस बात पर निर्भर करता है कि उन तरीकों के लिए सबमिट किए गए ऐसेट आईडी, कंपोज़िशन व्यू या कंपोज़िशन शेयर की पहचान करते हैं या नहीं.

  • contentOwnerAdvertisingOptions रिसॉर्स की नई claimedVideoOptions.autoGeneratedBreaks प्रॉपर्टी से पता चलता है कि YouTube को, दावा किए गए 10 मिनट से ज़्यादा लंबे वीडियो में, विज्ञापन के लिए अपने-आप ब्रेक जनरेट करने चाहिए या नहीं. इस प्रॉपर्टी का असर, कॉन्टेंट के मालिक के उन सभी वीडियो पर पड़ता है जो 10 मिनट से ज़्यादा के हैं. हालांकि, अगर किसी वीडियो पर एक से ज़्यादा दावे किए गए हैं, तो वीडियो पर दावा करने वाला पहला पार्टनर, उस वीडियो के लिए इस प्रॉपर्टी का डिफ़ॉल्ट व्यवहार सेट करता है.

11 अगस्त, 2016

इस अपडेट में ये बदलाव किए गए हैं:

  • YouTube API सेवाओं की नई शर्तें ("अपडेट की गई शर्तें") हाल ही में पब्लिश की गई हैं. इनके बारे में YouTube इंजीनियरिंग और डेवलपर ब्लॉग पर पूरी जानकारी दी गई है. इन शर्तों में, सेवा की मौजूदा शर्तों में किए गए कई अपडेट शामिल हैं. इस अपडेट में बदली गई शर्तें शामिल हैं. ये शर्तें 10 फ़रवरी, 2017 से लागू होंगी. साथ ही, इसमें उन नीतियों के बारे में बताने वाले कई दस्तावेज़ भी शामिल हैं जिनका डेवलपर को पालन करना होगा.

    नए दस्तावेज़ों का पूरा सेट, अपडेट किए गए नियमों के बदलाव के इतिहास में बताया गया है. इसके अलावा, बदलाव के इतिहास में यह भी बताया जाएगा कि आने वाले समय में, अपडेट की गई शर्तों या उनसे जुड़े दस्तावेज़ों में क्या बदलाव किए जाएंगे. उस दस्तावेज़ में मौजूद लिंक से, बदलावों के इतिहास में हुए बदलावों की सूची वाले आरएसएस फ़ीड की सदस्यता ली जा सकती है.

31 मई, 2016

इस अपडेट में ये बदलाव किए गए हैं:

  • नए संसाधन और तरीके

    • validator.validate के नए तरीके से यह पता लगाया जा सकता है कि मेटाडेटा फ़ाइल में पुष्टि से जुड़ी ऐसी गड़बड़ियां हैं या नहीं जिनकी वजह से YouTube उसे प्रोसेस नहीं कर पाएगा. अगर फ़ाइल में गड़बड़ियां हैं, तो एपीआई के जवाब की errors प्रॉपर्टी में पुष्टि से जुड़ी गड़बड़ियों की सूची होती है. इसमें हर गड़बड़ी की गंभीरता, वजह, और जगह की जानकारी होती है.

  • नई और अपडेट की गई गड़बड़ियां

    • assets.patch और assets.update तरीके अब इस गड़बड़ी के साथ काम करते हैं. आपको याद दिला दें कि एक तरीका, एक ही तरह की गड़बड़ियों के लिए काम कर सकता है. हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ देखें. इसके अलावा, हो सकने वाली गड़बड़ियों की पूरी सूची देखने के लिए, गड़बड़ियां पेज पर जाएं.

      गड़बड़ियां
      invalidValue (400) parameters.assetId
      अनुरोध पूरा नहीं हो सका, क्योंकि अपडेट की जा रही ऐसेट को किसी दूसरी ऐसेट के साथ मर्ज कर दिया गया है. assetId पैरामीटर की वैल्यू के तौर पर, गड़बड़ी के मैसेज में दिखाए गए उस एसेट के आईडी का इस्तेमाल करके, अनुरोध को फिर से सबमिट करें.

28 मार्च, 2016

इस अपडेट में ये बदलाव किए गए हैं:

  • मौजूदा रिसॉर्स और तरीकों में होने वाले अपडेट

    • claim रिसॉर्स की नई matchInfo.matchSegments[] प्रॉपर्टी में एक सूची होती है. इसमें हर आइटम, दावा किए गए वीडियो के उस सेगमेंट के बारे में बताता है जो पहचान फ़ाइल के हिस्से से मेल खाता है. किसी दावे में, मैच करने वाले कई सेगमेंट हो सकते हैं. उदाहरण के लिए, अगर अपलोड किए गए वीडियो का ऑडियो और वीडियो कॉन्टेंट, पहचान फ़ाइल वाले वीडियो से मेल खाता है, तो दो मैच सेगमेंट होंगे. एक सेगमेंट में ऑडियो मैच के बारे में जानकारी होगी और दूसरे में वीडियो मैच के बारे में जानकारी होगी.

      मैच होने वाले हर सेगमेंट के लिए, एपीआई, मैच होने वाले कॉन्टेंट की अवधि और टाइप (ऑडियो या वीडियो) दिखाता है. एपीआई, दावा किए गए वीडियो और रेफ़रंस वीडियो, दोनों में मिलते-जुलते हर सेगमेंट के शुरू और खत्म होने के समय के ऑफ़सेट की भी पहचान करता है.

    • contentOwnerAdvertisingOptions.patch या contentOwnerAdvertisingOptions.update मेथड को कॉल करने पर, contentOwnerAdvertisingOptions रिसॉर्स की claimedVideoOptions.newVideoDefaults[] प्रॉपर्टी की वैल्यू अब अपडेट की जा सकती है.

    • contentOwnerAdvertisingOptions संसाधन की रीड-ओनली allowedOptions.autoGeneratedBreaks प्रॉपर्टी अब काम नहीं करती.

  • नई और अपडेट की गई गड़बड़ियां

    • एपीआई के claims.update तरीके में, अब यह गड़बड़ी दिख सकती है. आपको याद दिला दें कि एक तरीका, एक ही तरह की गड़बड़ियों के लिए काम कर सकता है. हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ देखें. इसके अलावा, हो सकने वाली गड़बड़ियों की पूरी सूची देखने के लिए, गड़बड़ियां पेज पर जाएं.

      गड़बड़ियां
      badRequest (400) alreadyClaimed
      यह दावा, किसी मौजूदा दावे का डुप्लीकेट है और इसे अपडेट नहीं किया जा सकता.

    • assets.list तरीका कभी-कभी टाइम आउट हो जाता है और 500 एचटीटीपी रिस्पॉन्स कोड (Internal Server Error) दिखाता है. ऐसा तब होता है, जब अनुरोध में कई एसेट का डेटा शामिल होता है और fetchMatchPolicy पैरामीटर की वैल्यू effective होती है. अगर आपके assets.list अनुरोध में कई एसेट आईडी शामिल हैं और आपको 500 गड़बड़ी का मैसेज मिलता है, तो एक या उससे कम एसेट के लिए अनुरोध फिर से सबमिट करें.

    • references.insert गड़बड़ी के दस्तावेज़ को अपडेट किया गया है. इसमें बताया गया है कि अगर अनुरोध में खराब रेफ़रंस फ़ाइल अपलोड की जाती है, तो रेफ़रंस को प्रोसेस होने तक उस समस्या की पहचान नहीं की जा सकती. इसलिए, भले ही references.insert अनुरोध से 'सही' जवाब मिल जाए, लेकिन हो सकता है कि रेफ़रंस को सही तरीके से प्रोसेस न किया जा सके. हमारा सुझाव है कि रेफ़रंस डालने के बाद, references.list तरीके का इस्तेमाल करके पोल करें. इससे यह पक्का किया जा सकेगा कि रेफ़रंस उम्मीद के मुताबिक चालू है या नहीं.

3 फ़रवरी, 2016

इस अपडेट में ये बदलाव किए गए हैं:

  • मौजूदा रिसॉर्स और तरीकों में होने वाले अपडेट

    • एपीआई अब प्रॉडक्ट लिस्टिंग विज्ञापनों के साथ काम करता है. प्रॉडक्ट लिस्टिंग विज्ञापन, उन प्रॉडक्ट को हाइलाइट करते हैं जो वीडियो के कॉन्टेंट से जुड़े हैं या उसमें दिखाए गए हैं. ये विज्ञापन, वीडियो के दौरान दिखाए जाने वाले प्रायोजित कार्ड होते हैं. कार्ड, विज्ञापन सिस्टम की तरफ़ से अपने आप जोड़े जाते हैं. दर्शकों को कुछ सेकंड तक कार्ड का टीज़र दिखाई देता है और वे वीडियो के ऊपरी दाएं किनारे पर स्थित आइकॉन पर क्लिक करके भी कार्ड ब्राउज़ कर सकते हैं.

      इस बदलाव की वजह से, product_listing को अब इन प्रॉपर्टी की वैल्यू में शामिल किया जा सकता है:

      संसाधन/एपीआई का तरीका प्रॉपर्टी
      contentOwnerAdvertisingOptions allowedOptions.licAdFormats[]
      contentOwnerAdvertisingOptions allowedOptions.ugcAdFormats[]
      contentOwnerAdvertisingOptions claimedVideoOptions.newVideoDefaults[]
      videoAdvertisingOptions adFormats[]
      videoAdvertisingOptions.getEnabledAds countriesRestriction[].adFormats[]

    • assetSearch.list तरीके के नए createdBefore और createdAfter, एपीआई को सिर्फ़ किसी खास तारीख से पहले और/या बाद में बनाई गई एसेट दिखाने का निर्देश देते हैं.

    • assetSearch.list अनुरोध के एपीआई रिस्पॉन्स में, type प्रॉपर्टी अब art_track_video वैल्यू के साथ काम करती है. YouTube सहायता केंद्र पर, आर्ट ट्रैक वाले वीडियो के बारे में ज़्यादा जानकारी मिलती है.

    • claimSearch.list तरीका, इन नए पैरामीटर के साथ काम करता है:

      पैरामीटर
      referenceId यह फ़िल्टर पैरामीटर, उस रेफ़रंस का YouTube रेफ़रंस आईडी बताता है जिसके लिए आपको दावे वापस पाने हैं.
      inactiveReasons इस वैकल्पिक पैरामीटर की मदद से, एपीआई के रिस्पॉन्स में सिर्फ़ उन दावों को शामिल किया जा सकता है जो निष्क्रिय हैं. साथ ही, यह भी तय किया जा सकता है कि निष्क्रिय होने की वजह क्या है. पैरामीटर की परिभाषा में, उन इनऐक्टिव दावों के टाइप की सूची होती है जिनके लिए खोज की जा सकती है.
      partnerUploaded इस वैकल्पिक बूलियन पैरामीटर की मदद से, यह तय किया जा सकता है कि एपीआई के रिस्पॉन्स में सिर्फ़ पार्टनर के अपलोड किए गए दावे या ऐसे दावे शामिल हों जिन्हें पार्टनर ने अपलोड नहीं किया है.

    • reference संसाधन के नए references#origination ऑब्जेक्ट में, रेफ़रंस के सोर्स के बारे में जानकारी होती है.

    • references.insert तरीके से, अब YouTube के gfp_gen सॉफ़्टवेयर का इस्तेमाल करके जनरेट किए गए रेफ़रंस अपलोड किए जा सकते हैं. अगर आपने पहले से जनरेट किया गया फ़िंगरप्रिंट दिया है, तो अपलोड किए गए reference संसाधन में fpDirect प्रॉपर्टी की वैल्यू को true पर सेट करें.

      ध्यान दें कि इस बदलाव के बाद, रेफ़रंस अपलोड करते समय fpDirect प्रॉपर्टी सेट करने पर, एपीआई अब गड़बड़ी का मैसेज नहीं दिखाता.

  • नई और अपडेट की गई गड़बड़ियां

    दस्तावेज़ में अब whitelist संसाधन के तरीकों से मिली गड़बड़ियों की सूची दी गई है.

    इसके अलावा, नीचे दी गई टेबल में उन नई गड़बड़ियों के बारे में बताया गया है जिनके लिए एपीआई काम करता है. साथ ही, उन तरीकों के बारे में भी बताया गया है जिनसे हर गड़बड़ी दिख सकती है. ध्यान दें कि कोई तरीका एक ही तरह की कई गड़बड़ियां दिखा सकता है. ज़्यादा जानकारी के लिए, कृपया हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ या गड़बड़ियां पेज देखें.

    गड़बड़ियां
    badRequest (400) inappropriateCampaignTarget
    अगर कोई कैंपेन ऐसा वीडियो दिखाने की कोशिश करता है जो कुछ उपयोगकर्ताओं के लिए आपत्तिजनक हो सकता है, तो campaigns.insert और campaigns.update तरीके से यह गड़बड़ी दिखती है. इस गड़बड़ी को ठीक करने के लिए, कृपया हाइलाइट करने के लिए कोई दूसरा कॉन्टेंट चुनें.
    badRequest (400) canNotCreatePartnerUploadedClaimOnCompositionOrSoundRecordingAssets
    अगर किसी कंपोज़िशन या साउंड रिकॉर्डिंग ऐसेट के साथ, पार्टनर के ज़रिए अपलोड किया गया दावा करने की कोशिश की जाती है, तो claims.insert तरीका यह गड़बड़ी दिखाता है.
    badRequest (400) existingSoundRecordingOrMusicVideoClaim
    अगर किसी वीडियो में रिकॉर्ड किए गए संगीत पर पहले से ही दावा किया गया है, तो claims.insert तरीका यह गड़बड़ी दिखाता है. एपीआई के ज़रिए, सीधे कॉम्पोज़िशन वाले दावे नहीं जोड़े जा सकते.
    badRequest (400) asset_id
    अगर अनुरोध में किसी फ़ाइल के ज़रिए रेफ़रंस बनाने की कोशिश की गई है, लेकिन अनुरोध में कोई assetId नहीं दिया गया है, तो references.insert तरीका यह गड़बड़ी दिखाता है.
    badRequest (400) canNotBeActivated
    अगर रेफ़रंस को चालू नहीं किया जा सकता, तो references.update तरीका यह गड़बड़ी दिखाता है. ऐसा, रेफ़रंस की स्थिति या मालिकाना हक की शर्तों की वजह से हो सकता है.
    badRequest (400) videoNotClaimed
    अगर आपने उस वीडियो पर दावा नहीं किया है जिसके लिए आपको विज्ञापन के विकल्पों को वापस लाने की कोशिश करनी है, तो videoAdvertisingOptions.get तरीका यह गड़बड़ी दिखाता है. इस वजह से, अनुरोध की गई जानकारी आपके लिए उपलब्ध नहीं होती.

18 दिसंबर, 2015

यूरोपियन यूनियन (ईयू) के कानूनों के मुताबिक, ईयू में असली उपयोगकर्ताओं को कुछ जानकारी देना और उनसे सहमति लेना ज़रूरी है. इसलिए, यूरोपीय संघ के असली उपयोगकर्ताओं के लिए, आपको ईयू उपयोगकर्ता की सहमति से जुड़ी नीति का पालन करना होगा. हमने YouTube API की सेवा की शर्तों में, इस ज़रूरी शर्त की सूचना जोड़ी है.

21 अप्रैल, 2015

इस अपडेट में ये बदलाव किए गए हैं:

  • नया campaign रिसॉर्स, कॉन्टेंट के मालिक के किसी खास कैंपेन के बारे में बताता है. इसकी मदद से, कॉन्टेंट के मालिक दावा किए गए, उपयोगकर्ता के अपलोड किए गए वीडियो पर अपने कॉन्टेंट का प्रमोशन करने के लिए, एनोटेशन का इस्तेमाल कर सकते हैं. उदाहरण के लिए, कॉन्टेंट का मालिक ऐसा कैंपेन बना सकता है जो किसी फ़िल्म के वॉच पेज पर लिंक जोड़ता है. यह लिंक, उन सभी वीडियो के लिए जोड़ा जाता है जिन पर दावा किया गया है और जिनमें उस फ़िल्म के सीन शामिल हैं.

    एपीआई, get, list, insert, update, patch, और delete campaign संसाधनों के तरीकों के साथ काम करता है.

  • एपीआई, campaigns.get, campaigns.insert, campaigns.update, और campaigns.delete के नए तरीकों के लिए, कई नई गड़बड़ियों को दिखाता है.

30 मार्च, 2015

इस अपडेट में ये बदलाव किए गए हैं:

  • मौजूदा रिसॉर्स और तरीकों में होने वाले अपडेट

    • assetSearch.list तरीके के नए isrcs पैरामीटर की मदद से, ज़्यादा से ज़्यादा 50 ISRC की सूची दी जा सकती है. एपीआई के जवाब में, उन आईएसआरसी से जुड़ी ऐसेट शामिल होंगी.

    • claimHistory रिसॉर्स की event[].reason प्रॉपर्टी में, ये नई वैल्यू इस्तेमाल की जा सकती हैं. हर वजह से यह पता चलता है कि दावे से जुड़ा कोई खास इवेंट क्यों हुआ:

      • closed_audio_claim_on_visual_reference
      • closed_partner_exclusion
      • closed_reference_conflict

    • claimSearch.list तरीके के नए sort पैरामीटर से उस तरीके के बारे में पता चलता है जिसका इस्तेमाल, एपीआई रिस्पॉन्स में संसाधनों को ऑर्डर करने के लिए किया जाएगा. डिफ़ॉल्ट रूप से, संसाधनों को बनाने की तारीख के हिसाब से, सबसे नई से लेकर सबसे पुरानी तारीख तक के क्रम में लगाया जाता है. दावा किए गए कॉन्टेंट के लिए, संसाधनों को सबसे ज़्यादा से लेकर सबसे कम व्यू के हिसाब से भी क्रम में लगाया जा सकता है.

      ध्यान दें कि अगर claimSearch.list अनुरोध में status पैरामीटर की वैल्यू को appealed, disputed, pending, potential या routedForReview पर भी सेट किया जाता है, तो नतीजों को दावे की समीक्षा की समयसीमा खत्म होने के समय के हिसाब से क्रम में लगाया जाता है.

    • ownership.update और ownership.patch मेथड अब उन सभी प्रॉपर्टी की सही सूची दिखाते हैं जिन्हें इन मेथड को कॉल करते समय अपडेट किया जा सकता है. यह बदलाव, एपीआई दस्तावेज़ में किए गए सुधार को दिखाता है. इससे एपीआई की सुविधाओं में हुए बदलाव का पता नहीं चलता.

    • assets.get और assets.list तरीकों के लिए fetchMatchPolicy पैरामीटर, अब effective को इस्तेमाल की जा सकने वाली वैल्यू के तौर पर दिखाते हैं. इस वैल्यू से एपीआई सर्वर को, मिलते-जुलते वीडियो से जुड़ी वह नीति वापस लाने का निर्देश मिलता है जो YouTube, ऐसेट के लिए लागू करता है.

    • assets.list, claims.list, contentOwners.list, policies.list, publishers.list, और references.list तरीकों के लिए id पैरामीटर में अब यह ध्यान रखा जाता है कि उनकी पैरामीटर वैल्यू में, कॉमा से अलग किए गए ज़्यादा से ज़्यादा 50 आईडी हो सकते हैं.

  • नई और अपडेट की गई गड़बड़ियां

    नीचे दी गई टेबल में, उन नई गड़बड़ियों के बारे में बताया गया है जिनकी जानकारी एपीआई देता है. साथ ही, उन तरीकों के बारे में भी बताया गया है जिनसे हर गड़बड़ी की जानकारी मिल सकती है. ध्यान दें कि कोई तरीका एक ही तरह की कई गड़बड़ियां दिखा सकता है.

    ज़्यादा जानकारी के लिए, कृपया हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ या गड़बड़ियां पेज देखें.

    गड़बड़ी का टाइप गड़बड़ी की जानकारी ब्यौरा
    badRequest (400) tooManyIsrcs अगर isrcs पैरामीटर में 50 से ज़्यादा आईएसआरसी दिए गए हैं, तो assetSearch.list तरीका यह गड़बड़ी दिखाता है.
    badRequest (400) videoIsPrivate निजी वीडियो पर दावा करने पर, claims.insert तरीका यह गड़बड़ी दिखाता है. किसी वीडियो पर सिर्फ़ तब दावा किया जा सकता है, जब उसकी निजता सेटिंग public या unlisted पर सेट हो.
    notModified (304) blockOutsideOwnershipUnchanged अगर दावे पर मौजूद blockOutsideOwnership फ़्लैग में बदलाव नहीं किया जा सका, तो claims.update तरीका यह गड़बड़ी दिखाता है. यह गड़बड़ी कई वजहों से हो सकती है. एक सामान्य उदाहरण के तौर पर, ऐसा तब होता है, जब किए गए बदलाव का दावा किए गए वीडियो पर कोई असर न पड़े.

7 नवंबर, 2014

इस अपडेट में ये बदलाव किए गए हैं:

  • मौजूदा रिसॉर्स और तरीकों में होने वाले अपडेट

    • claimSearch.list तरीके के status पैरामीटर में अब routedForReview वैल्यू का इस्तेमाल किया जा सकता है. इस वैल्यू से, ऐसे दावों के नतीजे दिखते हैं जिनकी मैन्युअल समीक्षा की ज़रूरत होती है. यह समीक्षा, ऐसेट की मिलते-जुलते वीडियो से जुड़ी नीति के नियम के आधार पर की जाती है.

    • claimHistory रिसॉर्स की event[].reason प्रॉपर्टी में, ये नई वैल्यू इस्तेमाल की जा सकती हैं. हर वजह से यह पता चलता है कि दावे से जुड़ा कोई खास इवेंट क्यों हुआ:

      • closed_invalid_reference_segment
      • closed_noadsense
      • suspended_monetization_on_channel
      • video_content_modified

    • claim रिसॉर्स की origin.source प्रॉपर्टी, दावे के सोर्स की पहचान करती है. अब इसमें melodyMatch वैल्यू का इस्तेमाल किया जा सकता है. मेलोडी मैच वाले दावे से पता चलता है कि जिस वीडियो पर दावा किया गया है उसमें मौजूद संगीत कंपोज़िशन, रेफ़रंस में मौजूद संगीत कंपोज़िशन से मेल खाता है.

    • references.insert तरीके के दस्तावेज़ को अपडेट कर दिया गया है, ताकि यह सही तरीके से दिखाया जा सके कि एपीआई उस तरीके के लिए दो अलग-अलग एंडपॉइंट का इस्तेमाल करता है. इससे एपीआई की सुविधाओं में कोई बदलाव नहीं होता. यह मौजूदा दस्तावेज़ में सुधार है.

      • अगर अनुरोध में नई पहचान फ़ाइल अपलोड की जा रही है, तो सही एंडपॉइंट यह है:

        POST https://www.googleapis.com/upload/youtube/partner/v1/references

      • अगर अनुरोध में, दावा किए गए वीडियो को रेफ़रंस कॉन्टेंट के तौर पर इस्तेमाल करके रेफ़रंस बनाया जा रहा है, तो सही एंडपॉइंट यह है:

        POST https://www.googleapis.com/youtube/partner/v1/references

  • नई और अपडेट की गई गड़बड़ियां

    नीचे दी गई टेबल में, उन नई गड़बड़ियों के बारे में बताया गया है जिनकी जानकारी एपीआई देता है. साथ ही, उन तरीकों के बारे में भी बताया गया है जिनसे हर गड़बड़ी की जानकारी मिल सकती है. ध्यान दें कि कोई तरीका एक ही तरह की कई गड़बड़ियां दिखा सकता है.

    ज़्यादा जानकारी के लिए, कृपया हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ या गड़बड़ियां पेज देखें.

    गड़बड़ी का टाइप गड़बड़ी की जानकारी ब्यौरा
    badRequest (400) invalidLabelName अगर ऐसेट लेबल का नाम अमान्य है, तो assets.insert, assets.update, और assetLabels.insert तरीके से यह गड़बड़ी दिखती है. लेबल के नाम में दो से 30 वर्ण होने चाहिए. इनमें कोण वाले ब्रैकेट, कॉमा, कोलन, ऐंपरसैंड या लंबे पाइप वर्ण (|) शामिल नहीं हो सकते.
    badRequest (400) ownerHaveMaximumNumberOfLabels assets.insert, assets.update, और assetLabels.insert तरीके से यह गड़बड़ी तब दिखती है, जब कॉन्टेंट के मालिक ने पहले ही 2,500 यूनीक ऐसेट लेबल तय कर लिए हों. फ़िलहाल, यह संख्या ज़्यादा से ज़्यादा हो सकती है.
    badRequest (400) tooManyLabelsOnOneAsset assets.insert और assets.update तरीके से यह गड़बड़ी तब दिखती है, जब कोई एसेट पहले से ही 30 एसेट लेबल से जुड़ी हो. फ़िलहाल, एसेट लेबल जोड़ने की यह सबसे ज़्यादा संख्या है.
    badRequest (400) channelMonetizationSuspended अगर किसी वीडियो के चैनल को पार्टनर के दावों की वजह से निलंबित किया गया है, तो claims.insert और claims.update तरीके से यह गड़बड़ी दिखती है.
    badRequest (400) channelNotActive अगर किसी वीडियो का चैनल चालू नहीं है, तो claims.update मेथड यह गड़बड़ी दिखाता है.

  • अगर अनुरोध बॉडी में metadataMine.contentType प्रॉपर्टी मौजूद नहीं है, तो assets.insert और assets.update तरीके अब कुछ ऐसेट के लिए badRequest गड़बड़ी नहीं दिखाते.

23 सितंबर, 2014

इस अपडेट में ये बदलाव किए गए हैं:

  • कॉन्टेंट के मालिक के आईडी में बदलाव

    कॉन्टेंट के मालिक के आईडी में हुए बदलाव, 9 जुलाई, 2014 को बदलाव के इतिहास में बताए गए थे. ये बदलाव अब लागू हो गए हैं. इस बदलाव की वजह से, एपीआई अब जनरेट किया गया यूनीक आईडी दिखाता है. इससे, पुष्टि किए गए उपयोगकर्ता या एपीआई के ज़रिए मैनेज किए जा रहे संसाधन से जुड़े कॉन्टेंट के मालिक की पहचान की जा सकती है. पहले, एपीआई आईडी के तौर पर ऐसा नाम दिखाता था जिसे कोई भी आसानी से पढ़ सकता था. जैसे, "qrs_network."

    इस बदलाव का असर, एपीआई की नीचे दी गई सुविधाओं पर पड़ेगा. साथ ही, इस बदलाव का असर उन पार्टनर पर भी पड़ेगा जिन्होंने अपने ऐप्लिकेशन में पार्टनर कोड को हार्ड कोड किया है.

    • एपीआई अब उन रिसॉर्स प्रॉपर्टी की वैल्यू के तौर पर नया आईडी दिखाता है जो पहले पार्टनर कोड दिखाती थीं. जैसे, contentOwner रिसॉर्स की id प्रॉपर्टी.
    • एपीआई के सभी तरीके, onBehalfOfContentOwner पैरामीटर के साथ काम करते हैं. इससे उस कॉन्टेंट के मालिक की पहचान होती है जिसकी ओर से एपीआई का अनुरोध किया जा रहा है. बदलाव के बाद, पैरामीटर को पार्टनर कोड के बजाय नए आईडी पर सेट किया जाना चाहिए. कोड में रुकावट न आए, इसके लिए ट्रांज़िशन पीरियड के दौरान पैरामीटर, दोनों में से कोई भी वैल्यू स्वीकार करेगा.
    • बदलाव के बाद, contentOwners.list तरीके के contentOwnerId पैरामीटर में पार्टनर कोड के बजाय नया आईडी होना चाहिए.

  • मौजूदा रिसॉर्स और तरीकों में होने वाले अपडेट

    • assetSearch.list तरीके के नए metadataSearchFields पैरामीटर की मदद से, ऐसेट के उन मेटाडेटा फ़ील्ड को चुना जा सकता है जिन्हें आपको खोजना है. साथ ही, उन फ़ील्ड में खोजी जाने वाली वैल्यू भी चुना जा सकता है. पैरामीटर वैल्यू, फ़ील्ड और वैल्यू के जोड़े की सूची होती है. इसे कॉमा लगाकर अलग किया जाता है. किसी जोड़े में, फ़ील्ड और वैल्यू को कोलन लगाकर अलग किया जाता है.

    • claim रिसॉर्स का नया appliedPolicy ऑब्जेक्ट, उस नीति के बारे में बताता है जिसे YouTube दावे के लिए लागू करता है. ऑब्जेक्ट की वैल्यू, policy रिसॉर्स है. उस संसाधन में उन देशों के लिए नीति की जानकारी होती है जहां दावा की गई ऐसेट का मालिकाना हक, अनुरोध सबमिट करने वाले कॉन्टेंट के मालिक के पास होता है.

      लागू की गई नीति, कॉन्टेंट के मालिक की तय की गई नीति से दो तरीकों से अलग हो सकती है:

      1. इसमें उन अन्य मालिकों की सेट की गई नीतियों का भी ध्यान रखा जाता है जिनके पास दावा की गई ऐसेट का कुछ मालिकाना हक है. ये मालिक, उन ही देशों/इलाकों में ऐसेट के मालिक हैं जहां कॉन्टेंट के मालिक ने एपीआई अनुरोध सबमिट किया है.

      2. इसमें YouTube की उन एडमिनिस्ट्रेशन से जुड़ी नीतियों का ध्यान रखा जाता है जो उन देशों/इलाकों में लागू होती हैं जहां कॉन्टेंट के मालिक के पास दावा की गई ऐसेट का मालिकाना हक होता है.

    • claimHistory रिसॉर्स की नई uploaderChannelId प्रॉपर्टी, उस चैनल के चैनल आईडी की पहचान करती है जिस पर दावा किया गया वीडियो अपलोड किया गया था.

8 सितंबर, 2014

इस अपडेट में ये बदलाव किए गए हैं:

  • नए संसाधन और तरीके

    • नया assetLabel रिसॉर्स, किसी टेक्स्ट लेबल की पहचान करता है जिसे किसी एसेट को असाइन किया जा सकता है. ऐसेट लेबल की मदद से, ऐसेट को अपनी पसंद की कैटगरी में रखा जा सकता है. इससे अपनी ऐसेट लाइब्रेरी को मैनेज करना आसान हो जाता है. ऐसेट को उनके लेबल के हिसाब से खोजा जा सकता है. इससे, ऐसे इस्तेमाल के उदाहरणों को आसान बनाया जा सकता है जिनमें आपको ऐसेट के खास ग्रुप अपडेट करने होते हैं.

      • assetLabels.list तरीके से, कॉन्टेंट के मालिक के लेबल की सूची देखी जा सकती है.
      • assetLabels.insert तरीके से, नया ऐसेट लेबल बनाया जा सकता है. assets.update तरीके को कॉल करके और किसी ऐसेट के लेबल अपडेट करके भी नए लेबल बनाए जा सकते हैं. एपीआई सर्वर, पहले से तय नहीं किए गए किसी भी लेबल के लिए, अपने-आप एक नया assetLabel रिसॉर्स बना देगा.

  • मौजूदा रिसॉर्स और तरीकों में होने वाले अपडेट

    • asset रिसॉर्स की label[] प्रॉपर्टी को अपडेट किया गया है, ताकि यह जानकारी दी जा सके कि किसी ऐसेट के लेबल अपडेट करने के लिए, assets.update तरीके को कॉल किया जा सकता है. हालांकि, assets.insert तरीके को कॉल करते समय, एसेट के लेबल सेट नहीं किए जा सकते.

      ऐसेट लेबल इस्तेमाल करने से जुड़ी नई गाइड में, ऐसेट लेबल बनाने और उन्हें वापस पाने का तरीका बताया गया है. साथ ही, इसमें किसी ऐसेट के लेबल अपडेट करने या किसी खास लेबल से जुड़ी ऐसेट खोजने का तरीका भी बताया गया है.

  • नई और अपडेट की गई गड़बड़ियां

    एपीआई, नए assetLabels.list और assetLabels.insert तरीकों के लिए कई नई गड़बड़ियों को दिखाता है.

9 जुलाई, 2014

इस अपडेट में ये बदलाव किए गए हैं:

  • कॉन्टेंट के मालिक के आईडी में बदलाव

    पहले, एपीआई ने "qrs_network" जैसे ऐसे पार्टनर कोड का इस्तेमाल किया है जिसे कोई भी व्यक्ति पढ़ सकता है. इसका मकसद, पुष्टि किए गए उपयोगकर्ता या एपीआई के ज़रिए मैनेज किए जा रहे संसाधन से जुड़े कॉन्टेंट के मालिक की खास पहचान करना था. साल 2014 की तीसरी तिमाही में, एपीआई कॉन्टेंट के मालिकों की पहचान करने के लिए, 22 वर्णों के यूनीक आईडी का इस्तेमाल करेगा. इस बदलाव का असर, एपीआई की नीचे दी गई सुविधाओं पर पड़ेगा. साथ ही, इसकी वजह से उन पार्टनर पर भी असर पड़ सकता है जिन्होंने अपने ऐप्लिकेशन में पार्टनर कोड को हार्ड कोड किया है.

    • एपीआई, उन रिसॉर्स प्रॉपर्टी की वैल्यू के तौर पर 22 वर्ण वाला आईडी दिखाएगा जिन्होंने पहले पार्टनर कोड दिखाया था. जैसे, contentOwner रिसॉर्स की id प्रॉपर्टी.
    • एपीआई के सभी तरीके, onBehalfOfContentOwner पैरामीटर के साथ काम करते हैं. इससे उस कॉन्टेंट के मालिक की पहचान होती है जिसकी ओर से एपीआई का अनुरोध किया जा रहा है. बदलाव के बाद, पैरामीटर को पार्टनर कोड के बजाय 22 वर्णों वाले आईडी पर सेट किया जाना चाहिए. कोड में रुकावट न आए, इसके लिए ट्रांज़िशन पीरियड के दौरान पैरामीटर, दोनों में से कोई भी वैल्यू स्वीकार करेगा.
    • बदलाव के बाद, contentOwners.list तरीके के contentOwnerId पैरामीटर में पार्टनर कोड के बजाय 22 वर्णों वाला आईडी होना चाहिए.

  • मौजूदा रिसॉर्स और तरीकों में होने वाले अपडेट

    • asset रिसॉर्स में अब label प्रॉपर्टी का इस्तेमाल किया जा सकता है. इससे, ऐसेट से जुड़े ऐसेट लेबल की सूची मिलती है. आप एक से ज़्यादा एसेट को समूह में रखने के लिए उन पर लेबल लगा सकते हैं. इकट्ठा अपडेट करने, रिपोर्ट डाउनलोड करने या YouTube Analytics को फ़िल्टर करने के लिए, खोज फ़िल्टर के तौर पर लेबल का इस्तेमाल किया जा सकता है.

    • assetSearch.list तरीका अब इन वैकल्पिक पैरामीटर के साथ काम करता है:

      • labels: इससे खोज के नतीजों में सिर्फ़ उन ऐसेट को शामिल किया जाता है जो दिए गए लेबल से जुड़ी हैं. डिफ़ॉल्ट रूप से, एपीआई उन ऐसेट को दिखाता है जो बताए गए सभी लेबल से मैच करती हैं. हालांकि, includeAnyProvidedLabel पैरामीटर का इस्तेमाल करके, एपीआई को किसी भी तय किए गए लेबल से मैच करने वाली एसेट दिखाने का निर्देश दिया जा सकता है.
      • includeAnyProvidedLabel: labels पैरामीटर के साथ इस्तेमाल किया जाता है. यह पैरामीटर, एपीआई को labels पैरामीटर की वैल्यू में बताए गए किसी भी लेबल से जुड़ी ऐसेट दिखाने का निर्देश देता है.

    • claimHistory संसाधन में अब ये नई प्रॉपर्टी शामिल हैं:

      • event[].source.userEmail प्रॉपर्टी से, इवेंट शुरू करने वाले उपयोगकर्ता का ईमेल पता मिलता है.
      • event[].typeDetails.disputeNotes प्रॉपर्टी में, dispute_create इवेंट के लिए विवाद के नोट शामिल हैं.

    • claimSearch.list तरीका अब इन वैकल्पिक पैरामीटर के साथ काम करता है:

      • createdAfter: इस विकल्प की मदद से, नतीजों में सिर्फ़ उस तारीख के बाद किए गए दावे शामिल किए जा सकते हैं.
      • createdBefore: इस विकल्प की मदद से, नतीजों में सिर्फ़ उस तारीख से पहले किए गए दावे शामिल किए जा सकते हैं.
      • includeThirdPartyClaims: इस पैरामीटर का इस्तेमाल videoId पैरामीटर के साथ किया जाता है. इससे यह पता चलता है कि एपीआई के नतीजों में तीसरे पक्ष के दावे शामिल करने हैं या नहीं.

  • गड़बड़ी के बारे में ज़्यादा जानकारी

    गड़बड़ी से जुड़े दस्तावेज़ में, अब हर तरह की गड़बड़ी के लिए एचटीटीपी रिस्पॉन्स कोड बताया गया है.

  • नई और अपडेट की गई गड़बड़ियां

    नीचे दी गई टेबल में, उन नई गड़बड़ियों के बारे में बताया गया है जिनकी जानकारी एपीआई देता है. साथ ही, उन तरीकों के बारे में भी बताया गया है जिनसे हर गड़बड़ी की जानकारी मिल सकती है. ध्यान दें कि कोई तरीका एक ही तरह की कई गड़बड़ियां दिखा सकता है. उदाहरण के लिए, अगर कोई ऐसा asset संसाधन डालने की कोशिश की जाती है जिसमें ज़रूरी मेटाडेटा फ़ील्ड मौजूद नहीं है, तो required गड़बड़ी का मैसेज दिखता है. असल में, ज़रूरी मेटाडेटा फ़ील्ड एक से ज़्यादा हो सकते हैं. इनमें से हर फ़ील्ड में गड़बड़ी का मैसेज अलग-अलग होगा.

    ज़्यादा जानकारी के लिए, कृपया हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ या गड़बड़ियां पेज देखें.

    तरीका गड़बड़ियां
    assetSearch.list
    • invalidValue – एपीआई, शो या सीज़न की ऐसेट खोजने की सुविधा के साथ काम नहीं करता. type पैरामीटर की वैल्यू को इस्तेमाल की जा सकने वाली वैल्यू पर सेट करें.
    assets.insert
    • conflict – एक ही आइडेंटिफ़ायर (जैसे, कस्टम आईडी, आईएसआरसी वगैरह) वाली कई ऐसेट पहले से मौजूद हैं.
    • conflict – बताई गई ऐसेट की बहुत सारी कॉपी पहले से मौजूद हैं.
    • invalidValue – एपीआई को कॉल करने वाले उपयोगकर्ता के पास, बताए गए टाइप की एसेट बनाने की अनुमति नहीं है.
    assets.patch
    assets.update
    • badRequest – एपीआई, ऐसेट टाइप के उस कन्वर्ज़न के साथ काम नहीं करता जिसे आपने आज़माया है.
    claimSearch.list
    • badRequest – includeThirdPartyClaims पैरामीटर का इस्तेमाल सिर्फ़ videoId फ़िल्टर के साथ किया जा सकता है.
    ownership.patch
    ownership.update
    • badRequest – किसी आर्ट ट्रैक ऐसेट के मालिकाना हक को अपडेट नहीं किया जा सकता.
    references.patch
    references.update
    • badRequest – आपने जिस कार्रवाई को पूरा करने की कोशिश की है उसके लिए, रेफ़रंस अमान्य स्थिति में है.

3 फ़रवरी, 2014

इस अपडेट में ये बदलाव किए गए हैं:

  • मौजूदा रिसॉर्स और तरीकों में होने वाले अपडेट

    • किसी asset रिसॉर्स की type वैल्यू अब art_track_video हो सकती है.

    • claimSearch संसाधन में अब ये नई प्रॉपर्टी शामिल हैं:

      • origin ऑब्जेक्ट में, दावे को बनाने के तरीके के बारे में जानकारी होती है.
      • thirdPartyClaim प्रॉपर्टी में एक बूलियन वैल्यू होती है. इससे पता चलता है कि दावा, खोज करने वाले उपयोगकर्ता से जुड़े कॉन्टेंट के मालिक के बजाय, किसी दूसरे कॉन्टेंट के मालिक ने किया है या नहीं.

    • claimSearch.list तरीका अब इन वैकल्पिक पैरामीटर के साथ काम करता है:

      • contentType: इससे नतीजों में सिर्फ़ ऑडियो, वीडियो या ऑडियोविज़ुअल पर किए गए दावे शामिल होते हैं.
      • origin: इस फ़ील्ड में, दावे के एक या एक से ज़्यादा सोर्स की जानकारी दी जाती है. जैसे, descriptiveSearch या videoMatch. इन सोर्स के लिए, आपको दावे ढूंढने हैं.
      • status: इसकी मदद से, नतीजों में सिर्फ़ उन दावों को शामिल किया जा सकता है जिनकी स्थिति तय की गई है.

    • claim रिसॉर्स की status प्रॉपर्टी में अब ये वैल्यू भी इस्तेमाल की जा सकती हैं: appealed, disputed, potential, takedown, और unknown.

    • claim रिसॉर्स की नई blockOutsideOwnership प्रॉपर्टी से पता चलता है कि जिस वीडियो पर दावा किया गया है उसे उन देशों/इलाकों में ब्लॉक किया जाना चाहिए या नहीं जहां उसका मालिकाना हक साफ़ तौर पर आपके पास नहीं है. डिफ़ॉल्ट रूप से, दावा किए गए वीडियो को उन देशों में अब भी देखा जा सकेगा जहां दावे से जुड़ी एसेट के लिए मालिकाना हक का डेटा तय नहीं किया गया था.

    • contentOwnerAdvertisingOption रिसॉर्स की नई allowedOptions.autoGeneratedBreaks प्रॉपर्टी से पता चलता है कि पार्टनर, ब्रेक के दौरान YouTube की ओर से अपने-आप तय किए गए समय पर, बीच में दिखने वाले इन-स्ट्रीम विज्ञापन दिखाने का विकल्प चुन सकता है या नहीं.

    • contentOwners.list तरीके को अब अनुमति वाले उस टोकन के साथ कॉल किया जा सकता है जो https://www.googleapis.com/auth/youtubepartner-content-owner-readonly दायरे के बारे में बताता है.

    • policy रिसॉर्स की नई timeUpdated प्रॉपर्टी से पता चलता है कि नीति को आखिरी बार कब अपडेट किया गया था.

    • policies.list तरीके में अब sort पैरामीटर का इस्तेमाल किया जा सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. इसका इस्तेमाल यह तय करने के लिए किया जा सकता है कि नतीजों को, पिछली बार अपडेट होने के समय के हिसाब से, बढ़ते या घटते क्रम में क्रम से लगाया जाए.

    • referenceConflict रिसॉर्स की नई expiryTime प्रॉपर्टी से पता चलता है कि रेफ़रंस के लिए, विवाद की समीक्षा की अवधि कब खत्म होगी. इसकी वजह से, विवाद की समयसीमा खत्म हो जाएगी.

    • videoAdvertisingOption रिसॉर्स की नई autoGeneratedBreaks प्रॉपर्टी से पता चलता है कि वीडियो के बीच में दिखने वाले विज्ञापनों के लिए, ब्रेक के समय YouTube को अपने-आप तय करने की अनुमति देनी है या नहीं.

  • नई और अपडेट की गई गड़बड़ियां

    नीचे दी गई टेबल में, उन नई गड़बड़ियों के बारे में बताया गया है जिनकी जानकारी एपीआई देता है. साथ ही, उन तरीकों के बारे में भी बताया गया है जिनसे हर गड़बड़ी की जानकारी मिल सकती है. ध्यान दें कि कोई तरीका एक ही तरह की कई गड़बड़ियां दिखा सकता है. उदाहरण के लिए, अगर कोई ऐसा asset संसाधन डालने की कोशिश की जाती है जिसमें ज़रूरी मेटाडेटा फ़ील्ड मौजूद नहीं है, तो required गड़बड़ी का मैसेज दिखता है. असल में, ज़रूरी मेटाडेटा फ़ील्ड एक से ज़्यादा हो सकते हैं. इनमें से हर फ़ील्ड में गड़बड़ी का मैसेज अलग-अलग होगा.

    ज़्यादा जानकारी के लिए, कृपया हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ या गड़बड़ियां पेज देखें.

    तरीका गड़बड़ियां
    assets.insert
    assets.update
    • badRequest – एपीआई, आर्ट ट्रैक ऐसेट पर लिखने की सुविधा के साथ काम नहीं करता.
    claimSearch.list
    • invalidValue – अनुरोध में मौजूद pageToken पैरामीटर में अमान्य पेज टोकन दिया गया है.
    claims.insert
    • badRequest – आपने जो दावा किया है वह अमान्य है. ऐसा इसलिए है, क्योंकि वीडियो का चैनल चालू नहीं है.
    • badRequest – जिस वीडियो पर दावा किया जा रहा है वह वीडियो हटाने की नीति से छूट पाता है. ज़्यादा जानकारी के लिए, कृपया copyright@youtube.com पर संपर्क करें
    • badRequest – आपका अनुरोध प्रोसेस नहीं किया जा सकता, क्योंकि आपके पास बताए गए वीडियो पर तीसरे पक्ष का दावा करने का विकल्प नहीं है.
    • conflict – YouTube, अनुरोध किया गया दावा नहीं कर सकता, क्योंकि वीडियो पर वीडियो हटाने का नोटिस भेजा गया है.
    • conflict – YouTube, आपके अनुरोध के मुताबिक दावा नहीं कर सकता, क्योंकि वीडियो पर वीडियो हटाने का एक मान्य दावा है.
    references.insert
    • badRequest – जिस वीडियो पर दावा किया गया है उसका इस्तेमाल नहीं किया जा सकता. ऐसा इसलिए है, क्योंकि उसे मिटा दिया गया है या अस्वीकार कर दिया गया है. इसके अलावा, हो सकता है कि वीडियो को प्रोसेस नहीं किया जा सका हो.

  • contentOwnerNotProvided और internalError गड़बड़ियां, किसी खास एपीआई तरीके से जुड़ी नहीं होती हैं. इसलिए, अब इन्हें हर तरीके के पेज पर नहीं दिखाया जाता. हालांकि, इन गड़बड़ियों के बारे में जानकारी अब भी एपीआई की गड़बड़ी के दस्तावेज़ के सामान्य गड़बड़ियां सेक्शन में देखी जा सकती है.

12 सितंबर, 2013

इस अपडेट में ये बदलाव किए गए हैं:

  • नए संसाधन और तरीके

    • नया referenceConflict रिसॉर्स, दो पहचान फ़ाइलों के बीच होने वाले विरोध की पहचान करता है. साथ ही, विरोध की पहचान होने पर, उन फ़ाइलों के बीच मौजूद मैच की सूची बनाता है. referenceConflicts.list तरीके से, कॉन्टेंट के आधिकारिक मालिक से जुड़े, ऐसे रेफ़रंस के विवादों की सूची देखी जा सकती है जिन्हें हल नहीं किया गया है. referenceConflicts.get तरीके की मदद से, रेफ़रंस के यूनीक आईडी की जानकारी देकर, रेफ़रंस के अंतर को वापस पाया जा सकता है.

    मौजूदा रिसॉर्स और तरीकों में होने वाले अपडेट

    • एपीआई अब किसी ऐसेट के लिए, मिलते-जुलते वीडियो से जुड़ी लागू नीति को वापस लाने की सुविधा देता है. यह बदलाव, 16 जुलाई, 2013 को किए गए बदलावों से मेल खाता है. इन बदलावों में, किसी एसेट के लिए मेटाडेटा और मालिकाना हक के डेटा के कैननिकल सेट को वापस पाने की सुविधा शामिल थी.

      किसी ऐसेट के लिए लागू होने वाली मैच नीति को वापस पाने के लिए, assets.get या assets.list तरीकों को कॉल करते समय fetchMatchPolicy पैरामीटर की वैल्यू को effective पर सेट करें. एपीआई के जवाब में, दिखाए गए हर asset संसाधन के matchPolicyEffective ऑब्जेक्ट में, उस एसेट के लिए लागू मैच नीति होती है.

    • asset रिसॉर्स के नए ownershipConflicts ऑब्जेक्ट में, ऐसेट के मालिकाना हक से जुड़े विवादों की जानकारी होती है. ऑब्जेक्ट का स्ट्रक्चर, ownership रिसॉर्स के स्ट्रक्चर से मिलता-जुलता है. इससे, हर उस तरह के अधिकार की पहचान की जा सकती है जो एसेट के मालिक के पास हो सकते हैं. (ज़्यादातर तरह की ऐसेट के लिए, मालिकों के पास सिर्फ़ ऐसेट का सामान्य मालिकाना हक हो सकता है. हालांकि, कंपोज़िशन ऐसेट के लिए, मालिकों के पास परफ़ॉर्मेंस के अधिकारों, सिंक करने के अधिकारों या मैकेनिकल अधिकारों के मालिकाना हक की जानकारी हो सकती है.)

      इसी तरह, ownershipConflicts ऑब्जेक्ट में अलग-अलग सूचियां होती हैं. इनसे, सामान्य मालिकाना हक, परफ़ॉर्मेंस के अधिकार, सिंक करने के अधिकार, और मैकेनिकल अधिकारों से जुड़े विवादों की पहचान की जाती है. हर विवाद के लिए, डेटा उन देशों या इलाकों की पहचान करता है जहां विवाद होता है. साथ ही, उन मालिकों की पहचान करता है जिन्होंने मालिकाना हक से जुड़ा गलत डेटा दिया है. इसके अलावा, यह भी पता चलता है कि विवाद में शामिल हर मालिक ने ऐसेट के कितने प्रतिशत हिस्से पर मालिकाना हक का दावा किया है.

    • assets.get और assets.get तरीके अब नए fetchOwnershipConflicts पैरामीटर के साथ काम करते हैं. पैरामीटर में एक बूलियन वैल्यू होती है, जो यह बताती है कि एपीआई अनुरोध में, एपीआई के जवाब में एसेट के मालिकाना हक से जुड़े विवादों को वापस लाना चाहिए या नहीं. इसकी डिफ़ॉल्ट वैल्यू false है. इसका मतलब है कि मालिकाना हक से जुड़े विवादों की जानकारी नहीं दी जाती.

    • assetSearch.list तरीके के q पैरामीटर की परिभाषा को अपडेट किया गया है, ताकि उन मेटाडेटा फ़ील्ड की पहचान की जा सके जिन्हें YouTube खोजता है.

    • references.insert तरीके के लिए अनुरोध बॉडी के दस्तावेज़ से अब पता चलता है कि आपको contentType प्रॉपर्टी की वैल्यू सेट करनी होगी. इस बदलाव से दस्तावेज़ को अपडेट किया जाता है, ताकि एपीआई की असल सुविधाओं को सही तरीके से दिखाया जा सके. हालांकि, इससे एपीआई की सुविधाओं में कोई बदलाव नहीं होता.

  • नई और अपडेट की गई गड़बड़ियां

    • एपीआई में forbidden गड़बड़ी का एक नया कोड जोड़ा गया है. यह किसी खास तरीके के लिए नहीं है. इससे पता चलता है कि अनुरोध की गई कार्रवाई को सेवा खाते से अनुमति नहीं दी जा सकती.

    • assets.insert तरीका अब मेटाडेटा की गड़बड़ियों की पहचान, metadata ऑब्जेक्ट के बजाय metadataMine ऑब्जेक्ट की प्रॉपर्टी में होने वाली गड़बड़ियों के तौर पर करता है. metadata ऑब्जेक्ट को 16 जुलाई, 2013 को एपीआई अपडेट के बाद बंद कर दिया गया था.

    • गड़बड़ियां पेज को अपडेट किया गया है, ताकि update और patch तरीकों का इस्तेमाल करने वाले हर संसाधन के लिए, पेज पर एक टेबल हो. इस टेबल में, उन दोनों तरीकों से मिली गड़बड़ियों की सूची होती है. पहले, इस पेज पर हर तरीके की गड़बड़ियों की सूची अलग-अलग दिखती थी. हालांकि, ये सूचियां हमेशा एक जैसी होती थीं.

16 जुलाई, 2013

इस अपडेट में ये बदलाव किए गए हैं:

  • नए संसाधन और तरीके

    • claimHistory.get के नए तरीके से, किसी खास दावे की पहचान की जा सकती है और उसकी जानकारी वापस पाई जा सकती है. दिखाए गए claimHistory संसाधन में, दावे से जुड़े इवेंट की सूची होती है. जैसे, दावा किया जा रहा है, अपडेट किया जा रहा है, उस पर विवाद किया जा रहा है या उसे बंद किया जा रहा है.

    • claimSearch.list के नए तरीके से, ऐसे दावे खोजे जा सकते हैं जो इनमें से किसी एक या सभी शर्तों को पूरा करते हैं:

      • दावे किसी खास ऐसेट से जुड़े हों.
      • दावे किसी खास वीडियो से जुड़े हों.
      • दावे, अनुरोध में दी गई क्वेरी स्ट्रिंग से मेल खाते हैं.

      एपीआई रिस्पॉन्स में मौजूद हर claimSnippet रिसॉर्स में, दावे की जानकारी होती है. इसमें दावे का यूनीक आईडी, उसकी स्थिति, उसका टाइप (audio, video या audiovisual), और दावे से जुड़ी ऐसेट और वीडियो की जानकारी शामिल होती है. इस संसाधन से, दावा किए गए वीडियो के व्यू की संख्या और वीडियो का टाइटल भी पता चलता है.

  • मौजूदा रिसॉर्स और तरीकों में होने वाले अपडेट

    • दस्तावेज़ में अब उन प्रॉपर्टी के लिए इस्तेमाल की जा सकने वाली वैल्यू की सूची दी गई है जिनमें एनोटेट की गई वैल्यू का सेट है. ऐसी प्रॉपर्टी में, asset संसाधन की type प्रॉपर्टी और claim संसाधन की status प्रॉपर्टी शामिल होती है.

    • assets.get और assets.list तरीकों के लिए, एपीआई अब fetchMetadata और fetchOwnership अनुरोध पैरामीटर के लिए, कॉमा से अलग की गई वैल्यू का इस्तेमाल करता है. इससे, मेटाडेटा या मालिकाना हक के डेटा के कई सेट वापस पाए जा सकते हैं.

      नीचे दी गई सूची में, asset रिसॉर्स के स्ट्रक्चर में हुए बदलावों के बारे में बताया गया है. साथ ही, उन बदलावों के असर के बारे में भी बताया गया है जो get, list, insert, update या patch asset रिसॉर्स के एपीआई तरीकों पर पड़ेंगे.

      • metadata ऑब्जेक्ट को बंद कर दिया गया है और इसे metadataMine और metadataEffective ऑब्जेक्ट से बदल दिया गया है. नए ऑब्जेक्ट की मदद से, asset रिसॉर्स में एपीआई का अनुरोध करने वाले कॉन्टेंट के मालिक से मिले मेटाडेटा के सेट के साथ-साथ, मेटाडेटा का कैननिकल सेट भी शामिल किया जा सकता है. YouTube ने यह तय किया है कि ऐसेट के लिए, मेटाडेटा का कैननिकल सेट सबसे सटीक और पूरा सेट है.

      • इसी तरह, ownership ऑब्जेक्ट को ownershipMine और ownershipEffective ऑब्जेक्ट से बदल दिया गया है.

      • matchPolicy ऑब्जेक्ट को matchPolicyMine ऑब्जेक्ट से बदल दिया गया है. (फ़िलहाल, एपीआई किसी ऐसेट के लिए, लागू होने वाली मैच नीति को वापस पाने की सुविधा नहीं देता.)

      ध्यान दें: किसी एसेट के लिए, अगर सिर्फ़ एक मेटाडेटा वर्शन, मालिकाना हक के डेटा का एक सेट या मिलते-जुलते वीडियो की एक नीति का अनुरोध किया जाता है, तो एपीआई के रिस्पॉन्स में, पुराना ऑब्जेक्ट और साथ ही, काम करने वाला नया ऑब्जेक्ट भी शामिल होगा. ऐसा, पिछली रिलीज़ के साथ काम करने की सुविधा को बनाए रखने के लिए किया जाता है. उदाहरण के लिए, अगर कोई अनुरोध fetchMetadata पैरामीटर को mine पर सेट करता है, तो एपीआई के जवाब में एक metadata ऑब्जेक्ट और एक metadataMine ऑब्जेक्ट होगा. दोनों में एक ही डेटा होगा. (fetchMetadata=mine को सेट करने की सुविधा, सुविधा के अपडेट से पहले से काम कर रही थी. इससे आपको मेटाडेटा के कई वर्शन वापस पाने में मदद मिलती है.)

      हालांकि, अगर fetchMetadata पैरामीटर को mine,effective पर सेट किया जाता है, तो एपीआई के जवाब में metadataMine और metadataEffective ऑब्जेक्ट होंगे, लेकिन इसमें metadata ऑब्जेक्ट नहीं होगा. (इस सुविधा के अपडेट होने से पहले, fetchMetadata=mine,effective सेट करने की सुविधा काम नहीं करती थी. इसलिए, पुराने सिस्टम के साथ काम करने के लिए metadata ऑब्जेक्ट को वापस लाने की ज़रूरत नहीं है.) यही सिद्धांत fetchOwnership और fetchMatchPolicy पैरामीटर पर भी लागू होता है.

      इसी तरह, पुराने वर्शन के साथ काम करने की सुविधा के लिए, insert, update या patch asset संसाधन के अनुरोध में metadataMine ऑब्जेक्ट या metadata ऑब्जेक्ट शामिल किया जा सकता है. यही सिद्धांत, asset संसाधन के मालिकाना हक का डेटा या मैच करने की नीति सेट करने पर भी लागू होता है.

    • claims.list मेथड के assetId, q, और videoId पैरामीटर का इस्तेमाल नहीं किया जा सकता. इनमें से किसी भी शर्त का इस्तेमाल करके दावे खोजने के लिए, claimSearch.list तरीके का इस्तेमाल करें. यह तरीका, इन सभी पैरामीटर के साथ काम करता है.

    • ownership रिसॉर्स में, general[].ratio, performance[].ratio, synchronization[].ratio, और mechanical[].ratio प्रॉपर्टी की वैल्यू का कॉन्टेंट फ़ॉर्मैट अब integer के बजाय double है.

    • policy रिसॉर्स की rules[].action प्रॉपर्टी की परिभाषा में, अब उस प्रॉपर्टी की मान्य वैल्यू दी गई हैं: block, monetize, takedown, और track. हालांकि, ध्यान दें कि किसी दावे पर, कॉन्टेंट हटाने की नीति लागू करने के लिए, एपीआई का इस्तेमाल नहीं किया जा सकता.

    • reference रिसॉर्स की नई claimId प्रॉपर्टी तब मौजूद होती है, जब रेफ़रंस को किसी ऐसेट को किसी मौजूदा YouTube वीडियो से जोड़कर बनाया गया हो जिसे आपके सीएमएस खाते से लिंक किए गए YouTube चैनल पर अपलोड किया गया था. ऐसे मामले में, इस फ़ील्ड में उस दावे का आईडी होता है जो एसेट और वीडियो के बीच के असोसिएशन को दिखाता है.

    • reference रिसॉर्स की नई excludedIntervals[] प्रॉपर्टी, पहचान फ़ाइल के दौरान समय के ऐसे अंतराल की सूची बताती है जिन्हें पहचान फ़ाइल से मैच करते समय YouTube को अनदेखा करना चाहिए. हर इंटरवल में, वीडियो शुरू होने के बाद सेकंड में, शुरू और खत्म होने का समय बताया जाता है.

    • एपीआई को अब references.update या references.patch अनुरोध के मुख्य हिस्से में भेजे गए reference संसाधन में, status प्रॉपर्टी सेट करने की ज़रूरत नहीं है.

    • दस्तावेज़ में बदलाव किया गया है, ताकि videoAdvertisingOptions.getEnabledAds तरीके के लिए एपीआई रिस्पॉन्स फ़ॉर्मैट के बारे में सही तरीके से बताया जा सके. जवाब में यह जानकारी शामिल होती है. यह एक youtubePartner#videoAdvertisingOptionGetEnabledAds रिसॉर्स होता है:

      • id – यह एक आईडी है. इसका इस्तेमाल करके, YouTube सेटिंग से जुड़े उस वीडियो की खास पहचान करता है जिस पर दावा किया गया है.

      • adBreaks – ऑब्जेक्ट की सूची, जिसमें हर ऑब्जेक्ट में वीडियो चलाने से पहले, उसके दौरान या उसके बाद के उस पॉइंट की जानकारी होती है जब विज्ञापन दिखाए जा सकते हैं. हर ऑब्जेक्ट में, विज्ञापन के लिए ब्रेक के अन्य एट्रिब्यूट भी शामिल किए जा सकते हैं. जैसे, ब्रेक के दौरान दिखने वाले विज्ञापन स्लॉट और हर स्लॉट के दौरान दिखने वाले विज्ञापनों के टाइप.

      • adsOnEmbeds – यह एक बूलियन फ़ील्ड है. इससे पता चलता है कि एम्बेड किए गए प्लेयर में वीडियो चलने पर, YouTube विज्ञापन दिखा सकता है या नहीं.

      • countriesRestriction – ऑब्जेक्ट की सूची, जिसमें हर ऑब्जेक्ट से उन देशों/इलाकों की सूची और विज्ञापन फ़ॉर्मैट की जानकारी मिलती है जिनमें वीडियो चलाए जाते समय इनका इस्तेमाल किया जाता है.

  • नई और अपडेट की गई गड़बड़ियां

    • नीचे दी गई टेबल में, उन नई गड़बड़ियों के बारे में बताया गया है जिनकी जानकारी एपीआई देता है. साथ ही, उन तरीकों के बारे में भी बताया गया है जिनसे हर गड़बड़ी की जानकारी मिल सकती है. यह उन गड़बड़ियों की भी पहचान करता है जो बदल गई हैं. ध्यान दें कि कोई तरीका एक ही तरह की कई गड़बड़ियां दिखा सकता है. उदाहरण के लिए, अगर कोई ऐसा asset संसाधन डालने की कोशिश की जाती है जिसमें ज़रूरी मेटाडेटा फ़ील्ड मौजूद नहीं है, तो required गड़बड़ी का मैसेज दिखता है. असल में, ज़रूरी मेटाडेटा फ़ील्ड एक से ज़्यादा हो सकते हैं. इनमें से हर फ़ील्ड में गड़बड़ी का मैसेज अलग-अलग होगा.

      ज़्यादा जानकारी के लिए, कृपया हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ या गड़बड़ियां पेज देखें.

      तरीका गड़बड़ियां
      assets.insert
      assets.update
      assets.patch
      • invalidValue और required गड़बड़ियां, पहले metadata ऑब्जेक्ट की चाइल्ड प्रॉपर्टी से जुड़ी थीं. अब ये गड़बड़ियां metadataMine ऑब्जेक्ट की चाइल्ड प्रॉपर्टी से जुड़ी हैं.
      claimHistory.get
      • notFound – जिस दावे का इतिहास आपको वापस चाहिए वह नहीं मिला.
      • required – अनुरोध में claimId पैरामीटर के लिए कोई वैल्यू नहीं दी गई है.
      claimSearch.list
      claims.list
      • badRequest – अनुरोध में अमान्य शर्तें बताई गई हैं. ज़्यादा से ज़्यादा, इनमें से कोई एक फ़िल्टर पैरामीटर तय किया जा सकता है: q, assetId, videoId.
      claims.insert
      • badRequest – आपने जो दावा किया है वह अमान्य है. ऐसा इसलिए है, क्योंकि जिस कॉन्टेंट के लिए दावा किया गया है उसका मालिक, दावे से जुड़ी ऐसेट का मालिक नहीं है.
      • badRequest – कॉन्टेंट के जिस मालिक की ओर से आप कार्रवाई कर रहे हैं उसके पास, बताई गई कार्रवाई के साथ नीतियां बनाने की अनुमति नहीं है.
      • invalidValue – कॉन्टेंट के जिस मालिक की ओर से आप दावा कर रहे हैं उसके पास, एपीआई की मदद से उपयोगकर्ता के अपलोड किए गए वीडियो पर दावा करने की अनुमति नहीं है.
      contentOwners.list
      • badRequest – अनुरोध में अमान्य शर्तें बताई गई हैं. इनमें से किसी एक फ़िल्टर पैरामीटर की जानकारी देना ज़रूरी है: fetchMine, id. (पहले, गड़बड़ी की जानकारी में फ़िल्टर पैरामीटर का एक अलग सेट दिया गया था – has_conflicts_with, restrict_to_user, name_prefix, और id.)
      ownership.update
      ownership.patch
      • badRequest – किसी कंपोज़िशन एसेट के मालिकाना हक के डेटा को अपडेट करने वाले अनुरोध में, general मालिकाना हक के बजाय, मालिकाना हक का ज़्यादा जानकारी वाला डेटा &ndahs; mechanical, performance, synchronization, और/या lyric अधिकारों की जानकारी देनी होगी. lyric टाइप के अधिकारों का इस्तेमाल करने की सुविधा हाल ही में जोड़ी गई है.
      policies.insert
      policies.update
      policies.patch
      • invalidValue – अनुरोध में नीति का अमान्य नियम है, क्योंकि एपीआई, takedown कार्रवाई की जानकारी देने वाली नीतियों को बनाने या उनमें बदलाव करने की सुविधा नहीं देता. यह गड़बड़ी, invalidPolicyTakedownAction की वजह बताती है. यह गड़बड़ी, अब काम न करने वाली invalidPolicyConditionalTakedown गड़बड़ी की जगह लेगी.
      references.insert
      • badRequest – अनुरोध में मीडिया फ़ाइल भेजी जानी चाहिए या claimId अनुरोध पैरामीटर के लिए कोई वैल्यू दी जानी चाहिए. हालांकि, हो सकता है कि अनुरोध में मीडिया फ़ाइल न भेजी जाए और claimId अनुरोध पैरामीटर की वैल्यू न दी जाए.
      • badRequest – उसी YouTube वीडियो पर किसी दूसरे दावे से, उसी कॉन्टेंट के लिए पहचान फ़ाइल पहले ही बनाई जा चुकी है.
      • badRequest – रेफ़रंस बनाते समय, एपीआई fpDirect प्रॉपर्टी के लिए वैल्यू सेट करने की सुविधा नहीं देता.
      • internalError – अपलोड की गई मीडिया फ़ाइल में कोई समस्या है.
      • invalidValue – contentType, assetId या claimId अनुरोध पैरामीटर की वैल्यू अमान्य है. गड़बड़ी की जानकारी में, अमान्य वैल्यू की जानकारी होती है.
      • notFound – आपने जो एसेट या दावा किया है वह नहीं मिला. कृपया अपने अनुरोध में assetId और claimId पैरामीटर की वैल्यू देखें.
      • required – अनुरोध में contentType पैरामीटर की वैल्यू होनी चाहिए.
      references.insert
      references.update
      references.patch
      • invalidValue – रेफ़रंस के लिए बताई गई excludedIntervals अमान्य है. ध्यान दें कि किसी रेफ़रंस को बंद करते समय, बाहर रखे गए सेगमेंट के लिए समयावधि नहीं दी जा सकती.

10 मई, 2013

इस अपडेट में ये बदलाव किए गए हैं:

8 अप्रैल, 2013

इस अपडेट में ये बदलाव किए गए हैं:

  • इस एपीआई का नाम बदलकर, YouTube Content ID API कर दिया गया है.

  • assetMatchPolicy संसाधन में कई प्रॉपर्टी बदल गई हैं:

    • kind प्रॉपर्टी की वैल्यू, youtubePartner#policy से बदलकर youtubePartner#assetMatchPolicy हो गई है.
    • नई policyId प्रॉपर्टी में एक वैल्यू होती है, जो सेव की गई नीति के संसाधन की खास तौर पर पहचान करती है.
    • rules[].subaction प्रॉपर्टी की वैल्यू अब स्ट्रिंग के बजाय स्ट्रिंग की सूची है.
    • rules[].conditions.contentMatchType प्रॉपर्टी की वैल्यू अब स्ट्रिंग के बजाय स्ट्रिंग की सूची है.
    • id, name, और description प्रॉपर्टी हटा दी गई हैं.

  • assetMatchPolicy.update तरीके के दस्तावेज़ को अपडेट किया गया है, ताकि यह जानकारी दी जा सके कि इस तरीके को कॉल करते समय, policyId प्रॉपर्टी या rules[] ऑब्जेक्ट में से किसी एक के लिए वैल्यू सेट की जा सकती है.

  • claims रिसॉर्स अब कई नई प्रॉपर्टी के साथ काम करता है:

    प्रॉपर्टी का नाम मान ब्यौरा
    timeCreated datetime दावा करने की तारीख और समय.
    matchInfo object matchInfo ऑब्जेक्ट में, मैच होने वाले उस कॉन्टेंट के बारे में जानकारी होती है जिसकी वजह से दावा जनरेट हुआ है. यह जानकारी सिर्फ़ तब claim संसाधन में शामिल की जाती है, जब अपलोड किया गया वीडियो किसी मौजूदा रेफ़रंस फ़ाइल से मेल खाने की वजह से दावा अपने-आप जनरेट हुआ हो.
    matchInfo.referenceId string YouTube इस यूनीक आईडी का इस्तेमाल, मैच जनरेट करने वाले रेफ़रंस reference की पहचान करने के लिए करता है.
    matchInfo.longestMatch object longestMatch ऑब्जेक्ट में, रेफ़रंस और अपलोड किए गए वीडियो के बीच सबसे ज़्यादा मैच होने की जानकारी होती है.
    matchInfo.longestMatch.durationSecs unsigned long मैच की अवधि, सेकंड में.
    matchInfo.longestMatch.userVideoOffset unsigned long मैच शुरू होने का समय ऑफ़सेट. इसे अपलोड किए गए वीडियो की शुरुआत से सेकंड में मेज़र किया जाता है.
    matchInfo.longestMatch.referenceOffset unsigned long मैच शुरू होने का समय ऑफ़सेट, जिसे रेफ़रंस की शुरुआत से सेकंड में मेज़र किया जाता है.
    matchInfo.totalMatch object totalMatch ऑब्जेक्ट में, रेफ़रंस से मैच करने वाले अपलोड किए गए वीडियो की कुल अवधि और अपलोड किए गए वीडियो से मैच करने वाले रेफ़रंस की कुल अवधि की जानकारी होती है. अगर मैच होने वाला कॉन्टेंट, अपलोड किए गए वीडियो या रेफ़रंस में लूप में चलता है, तो ये वैल्यू अलग-अलग हो सकती हैं. उदाहरण के लिए, अगर अपलोड किए गए वीडियो में किसी पहचान फ़ाइल की 10 सेकंड की क्लिप शामिल है, लेकिन क्लिप को छह बार दोहराया गया है, तो अपलोड किए गए वीडियो में मैच होने वाला कुल कॉन्टेंट 60 सेकंड का होगा. हालांकि, पहचान फ़ाइल में मैच होने वाला कुल कॉन्टेंट सिर्फ़ 10 सेकंड का होगा.
    matchInfo.totalMatch.userVideoDurationSecs unsigned long अपलोड किए गए वीडियो का वह हिस्सा जो पहचान फ़ाइल से मेल खाता है और उसकी कुल अवधि सेकंड में.
    matchInfo.totalMatch.referenceDurationSecs unsigned long अपलोड किए गए वीडियो से मेल खाने वाले पहचान वाले वीडियो की कुल अवधि, सेकंड में.
    origin object origin ऑब्जेक्ट में, दावे के सोर्स की जानकारी होती है.
    origin.source string दावे का सोर्स.

  • claims संसाधन में policy प्रॉपर्टी को अपडेट किया गया है, ताकि यह नोट किया जा सके कि 'ऑडियो बदलें' सुविधा के दावे के लिए वैल्यू अपडेट नहीं की जा सकती.

  • metadataHistory रिसॉर्स की timeProvidedMs प्रॉपर्टी का नाम बदलकर timeProvided कर दिया गया है.

  • ownershipHistory रिसॉर्स की timeProvidedMs प्रॉपर्टी का नाम बदलकर timeProvided कर दिया गया है.

  • ownershipHistory.list तरीके की परिभाषा को अपडेट कर दिया गया है. इससे यह पता चलता है कि यह तरीका, कॉन्टेंट के हर मालिक के लिए मालिकाना हक का सिर्फ़ सबसे नया डेटा ही वापस लाता है. हालांकि, अगर कॉन्टेंट के मालिक ने कई डेटा सोर्स (एपीआई, कॉन्टेंट फ़ीड वगैरह) के ज़रिए मालिकाना हक का डेटा सबमिट किया है, तो सूची में हर कॉन्टेंट के मालिक और डेटा सोर्स का सबसे नया डेटा शामिल होगा.

  • policy संसाधन में कई प्रॉपर्टी बदल गई हैं:

    • rule प्रॉपर्टी का नाम बदलकर rules कर दिया गया है.
    • rules[].subaction प्रॉपर्टी की वैल्यू अब स्ट्रिंग के बजाय स्ट्रिंग की सूची है.
    • rules[].conditions.contentMatchType प्रॉपर्टी की वैल्यू अब स्ट्रिंग के बजाय स्ट्रिंग की सूची है.

  • policies.insert और policies.update तरीकों के दस्तावेज़ को अपडेट किया गया है. इससे यह पता चलता है कि उन तरीकों को कॉल करते समय, rules[] ऑब्जेक्ट के लिए वैल्यू सेट की जा सकती हैं.

  • एपीआई के कई तरीके, गड़बड़ी के नए टाइप के साथ काम करते हैं. नीचे दी गई टेबल में, गड़बड़ी का पता लगाने का तरीका बताया गया है. साथ ही, इसमें उन नई गड़बड़ियों के बारे में भी बताया गया है जिनका पता लगाया जा सकता है. कई मामलों में, किसी एक टाइप के लिए कई गड़बड़ियां हो सकती हैं. उदाहरण के लिए, अगर कोई ऐसा asset संसाधन डालने की कोशिश की जाती है जिसमें ज़रूरी मेटाडेटा फ़ील्ड मौजूद नहीं है, तो required गड़बड़ी का मैसेज दिखता है. असल में, ज़रूरी मेटाडेटा फ़ील्ड एक से ज़्यादा हो सकते हैं. इनमें से हर फ़ील्ड में गड़बड़ी का मैसेज अलग-अलग होगा.

    ज़्यादा जानकारी के लिए, कृपया हर तरीके के लिए गड़बड़ी से जुड़ा दस्तावेज़ या गड़बड़ियां पेज देखें.

    तरीका गड़बड़ियां
    assets.insert
    • invalidValue – किसी एसेट मेटाडेटा फ़ील्ड में अमान्य वैल्यू दी गई है.
    • required – एसेट मेटाडेटा का ज़रूरी फ़ील्ड मौजूद नहीं है.
    assets.update
    assets.patch
    • forbidden – अपडेट की जा रही ऐसेट का मालिकाना हक, अपडेट करने की कोशिश कर रहे पार्टनर के पास नहीं है.
    • invalidValue – किसी एसेट मेटाडेटा फ़ील्ड में अमान्य वैल्यू दी गई है.
    • notFound – ऐसेट को किसी ऐसी सीज़न ऐसेट या शो ऐसेट से जोड़ा जा रहा है जो नहीं मिल रही है.
    • required – एसेट मेटाडेटा का ज़रूरी फ़ील्ड मौजूद नहीं है.
    claims.insert
    • badRequest – अनुरोध में किसी वीडियो पर दावा करने की कोशिश की गई है, लेकिन दावा करने की अनुमति नहीं है.
    ownership.update
    ownership.patch
    • badRequest – अनुरोध में किसी देश या इलाके में, मालिकाना हक का कुल प्रतिशत 100 प्रतिशत से ज़्यादा बताया गया है.
    policies.insert
    policies.patch
    policies.update
    • conflictingPolicyRules – नीति में, एक-दूसरे से मेल न खाने वाले नियम शामिल हैं.

  • गड़बड़ियां वाले नए पेज पर, उन गड़बड़ियों की सूची होती है जो एपीआई दिखा सकता है. इस पेज पर सामान्य गड़बड़ियां शामिल होती हैं, जो एपीआई के कई अलग-अलग तरीकों के लिए हो सकती हैं. साथ ही, इसमें किसी खास तरीके से जुड़ी गड़बड़ियां भी शामिल होती हैं.

18 जनवरी, 2013

इस अपडेट में ये बदलाव किए गए हैं:

  • हाल ही में दस्तावेज़ में शामिल किए गए videoAdvertisingOptions.getEnabledAds तरीके की मदद से, किसी खास पार्टनर या उपयोगकर्ता के अपलोड किए गए वीडियो के लिए, विज्ञापन के उन टाइप के बारे में जानकारी हासिल की जा सकती है जिनकी अनुमति है.

  • assetSearch.list तरीके के ownershipRestriction पैरामीटर की परिभाषा को अपडेट किया गया है. इससे यह पता चलता है कि पैरामीटर की डिफ़ॉल्ट वैल्यू mine है. इससे पता चलता है कि एपीआई को सिर्फ़ मौजूदा उपयोगकर्ता के मालिकाना हक वाली एसेट को वापस लाना चाहिए.

  • assets.list तरीके के दस्तावेज़ में ये बदलाव दिखते हैं:

    • id पैरामीटर अब ज़रूरी है.

    • नए fetchMatchPolicy पैरामीटर की मदद से, यह बताया जा सकता है कि एपीआई अनुरोध में, एसेट के लिए सेट की गई मिलते-जुलते वीडियो से जुड़ी नीति को भी वापस पाना चाहिए या नहीं.

    • नए fetchOwnership पैरामीटर की मदद से, यह बताया जा सकता है कि एपीआई अनुरोध में ऐसेट के मालिकाना हक का डेटा भी वापस पाना चाहिए या नहीं.

    • एपीआई की ओर से दिखाए जाने वाली एसेट की सूची में, अब पेजेशन डेटा नहीं होता. इस वजह से, एपीआई के जवाब से nextPageToken प्रॉपर्टी और pageInfo ऑब्जेक्ट, दोनों को हटा दिया गया है. pageInfo ऑब्जेक्ट में totalResults, resultsPerPage, और startIndex प्रॉपर्टी शामिल थीं.

  • claims संसाधन दस्तावेज़ को अपडेट किया गया है. इसमें बताया गया है कि दावा करते समय आपको नीति की जानकारी देनी होगी. (अगर डाले गए दावे में किसी नीति के बारे में नहीं बताया गया है, तो YouTube फ़िलहाल इस्तेमाल की डिफ़ॉल्ट नीति लागू नहीं करता. हालांकि, दस्तावेज़ में पहले बताया गया था कि ऐसा किया गया था.)

  • policy संसाधन की hasUnpublishedDraft प्रॉपर्टी अब काम नहीं करती.

  • policies.list तरीके के साथ काम करने वाले नए id पैरामीटर की मदद से, सेव की गई उन नीतियों की पहचान की जा सकती है जिन्हें एपीआई अनुरोध से वापस पाना है. सिर्फ़ उस कॉन्टेंट के मालिक की नीतियां वापस पाई जा सकती हैं जिसकी पुष्टि हो चुकी है.

  • references.patch और references.update, दोनों तरीकों के लिए releaseClaims पैरामीटर की परिभाषा को अपडेट कर दिया गया है. इससे यह पता चलता है कि पैरामीटर सिर्फ़ तब काम करता है, जब दावे का स्टेटस inactive पर अपडेट किया जा रहा हो. ऐसे में, रेफ़रंस से जनरेट हुए मैच के सभी दावों को रिलीज़ करने के लिए, releaseClaims पैरामीटर की वैल्यू को true पर भी सेट किया जा सकता है.

  • references.patch और references.update, दोनों तरीकों को अपडेट कर दिया गया है. इससे यह पता चलता है कि इनमें से कोई भी कार्रवाई करते समय, आपको रेफ़रंस की स्थिति बतानी होगी.

  • एपीआई के कई तरीके, गड़बड़ी के नए टाइप के साथ काम करते हैं. यहां दी गई टेबल में, गड़बड़ी का पता लगाने का तरीका और नई गड़बड़ियों के बारे में बताया गया है:

    तरीका गड़बड़ी का टाइप गड़बड़ी की जानकारी ब्यौरा
    guideCategories.list notFound Unavailable जिस एसेट के लिए मैच नीति वापस लाने की कोशिश की जा रही है वह नहीं मिली.
    claims.get notFound Unavailable जिस दावे को वापस पाने की कोशिश की जा रही है वह नहीं मिला.
    ownership.patch invalidValue Unavailable आपने मालिकाना हक के लिए जो डेटा दिया है उसमें अमान्य वैल्यू दी गई है.
    ownership.update invalidValue Unavailable आपने मालिकाना हक के लिए जो डेटा दिया है उसमें अमान्य वैल्यू दी गई है.