Firebase is back at Google I/O on May 14! Register now.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

FCM मैसेज के बारे में जानकारी

Firebase क्लाउड से मैसेज (FCM), मैसेज सेवा के कई विकल्प और सुविधाएं देता है. इस पेज पर दी गई जानकारी का मकसद यह समझने में आपकी मदद करना है कि अलग-अलग तरह के FCM मैसेज क्या हैं और उनके साथ क्या किया जा सकता है.

मैसेज के टाइप

FCM से, आप क्लाइंट को दो तरह के मैसेज भेज सकते हैं:

सूचना मैसेज, जिन्हें कभी-कभी "डिसप्ले मैसेज" भी कहा जाता है. इन्हें FCM SDK टूल अपने-आप मैनेज करता है.
डेटा मैसेज, जिन्हें क्लाइंट ऐप्लिकेशन मैनेज करता है.

सूचना मैसेज में, उपयोगकर्ता को दिखने वाली कुंजियों का पहले से तय सेट होता है. हालांकि, डेटा मैसेज में सिर्फ़ उपयोगकर्ता की ओर से तय कस्टम की-वैल्यू पेयर होते हैं. सूचना मैसेज में एक वैकल्पिक डेटा पेलोड हो सकता है. दोनों तरह के मैसेज के लिए ज़्यादा से ज़्यादा पेलोड 4096 बाइट का होता है. हालांकि, Firebase कंसोल से मैसेज भेजते समय यह सीमा 1, 000 वर्णों की हो सकती है.

	स्थिति का इस्तेमाल करें	कैसे भेजें
सूचना मैसेज	FCM SDK टूल, असली उपयोगकर्ता के डिवाइसों पर क्लाइंट ऐप्लिकेशन की ओर से मैसेज तब दिखाता है, जब वह बैकग्राउंड में चल रहा होता है. ऐसा न होने पर, अगर सूचना मिलने के दौरान ऐप्लिकेशन फ़ोरग्राउंड में चल रहा हो, तो ऐप्लिकेशन के कोड से यह तय होता है कि वह काम कर रहा है या नहीं. सूचना वाले मैसेज में, उपयोगकर्ता को दिखने वाली कुंजियों का पहले से तय सेट और कस्टम की-वैल्यू पेयर का एक वैकल्पिक डेटा पेलोड होता है.	Cloud Functions या आपके ऐप्लिकेशन सर्वर जैसे किसी भरोसेमंद एनवायरमेंट में, एडमिन SDK टूल या एचटीटीपी v1 एपीआई का इस्तेमाल करें. `notification` कुंजी सेट करें. इसमें वैकल्पिक डेटा पेलोड हो सकता है. इसे हमेशा छोटा किया जा सकता है. डिसप्ले की जाने वाली सूचनाओं के कुछ उदाहरण देखें और अनुरोध पेलोड भेजें. सूचनाएं बनाने वाले का इस्तेमाल करें: मैसेज टेक्स्ट, टाइटल वगैरह डालें और भेजें. कस्टम डेटा देकर, वैकल्पिक डेटा पेलोड जोड़ें.
डेटा मैसेज	क्लाइंट ऐप्लिकेशन पर, डेटा मैसेज को प्रोसेस किया जाता है. डेटा मैसेज में सिर्फ़ कस्टम की-वैल्यू पेयर होते हैं, जिनके लिए कोई रिज़र्व नहीं किया गया कुंजी नाम नहीं होता है (नीचे देखें).	Cloud Functions या अपने ऐप्लिकेशन सर्वर जैसे भरोसेमंद एनवायरमेंट में, एडमिन SDK टूल या FCM सर्वर प्रोटोकॉल इस्तेमाल करें. भेजने के अनुरोध में, `data` कुंजी सेट करें.

सूचना वाले मैसेज का इस्तेमाल तब करें, जब आपकी इच्छा हो कि FCM SDK बैकग्राउंड में आपका ऐप्लिकेशन चलने के दौरान, अपने-आप सूचना दिखाए जाने की सुविधा को हैंडल करे. डेटा मैसेज का इस्तेमाल तब करें, जब आपको अपने क्लाइंट ऐप्लिकेशन कोड से मैसेज प्रोसेस करने हों.

FCM एक सूचना मैसेज भेज सकता है, जिसमें वैकल्पिक डेटा पेलोड शामिल होता है. ऐसे मामलों में, FCM, सूचना पेलोड दिखाने को हैंडल करता है और क्लाइंट ऐप्लिकेशन, डेटा पेलोड हैंडल करता है.

सूचना वाले मैसेज

टेस्टिंग या मार्केटिंग और उपयोगकर्ताओं को फिर से जोड़ने के लक्ष्य के लिए, Firebase कंसोल का इस्तेमाल करके सूचना वाले मैसेज भेजे जा सकते हैं. Firebase कंसोल, आंकड़ों पर आधारित A/B टेस्टिंग की सुविधा देता है. इसकी मदद से, मार्केटिंग मैसेज को बेहतर बनाया जा सकता है और उसे बेहतर बनाया जा सकता है.

एडमिन SDK या FCM प्रोटोकॉल का इस्तेमाल करके, प्रोग्राम के हिसाब से सूचना वाले मैसेज भेजने के लिए, notification कुंजी को उपयोगकर्ता को दिखने वाले सूचना मैसेज के मुख्य-वैल्यू विकल्पों के ज़रूरी सेट के साथ सेट करें. उदाहरण के लिए, यहां IM ऐप्लिकेशन में JSON-फ़ॉर्मैट वाला सूचना मैसेज दिया गया है. उपयोगकर्ता को डिवाइस पर "पुर्तगाल बनाम डेनमार्क" शीर्षक वाला और "शानदार मिलान!" वाला मैसेज दिख सकता है:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    }
  }
}

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

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

डेटा मैसेज

क्लाइंट ऐप्लिकेशन को डेटा पेलोड भेजने के लिए, अपने कस्टम की-वैल्यू पेयर के साथ सही कुंजी सेट करें.

उदाहरण के लिए, यहां ऊपर बताए गए IM ऐप्लिकेशन में JSON फ़ॉर्मैट वाला एक मैसेज दिया गया है. इसमें जानकारी को सामान्य data कुंजी में सेव किया जाता है और क्लाइंट ऐप्लिकेशन से कॉन्टेंट को समझने की उम्मीद की जाती है:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    }
  }
}

ऊपर दिया गया उदाहरण टॉप-लेवल या सामान्य data फ़ील्ड के इस्तेमाल के बारे में बताता है, जिसका इस्तेमाल क्लाइंट, मैसेज पाने वाले सभी प्लैटफ़ॉर्म पर करते हैं. हर प्लैटफ़ॉर्म पर, क्लाइंट ऐप्लिकेशन को कॉलबैक फ़ंक्शन में डेटा पेलोड मिलता है.

डेटा मैसेज को एन्क्रिप्ट (सुरक्षित) करना

Android ट्रांसपोर्ट लेयर (FCM आर्किटेक्चर देखें) पॉइंट-टू-पॉइंट एन्क्रिप्शन का इस्तेमाल करता है. अपनी ज़रूरत के हिसाब से, डेटा मैसेज में एंड-टू-एंड एन्क्रिप्शन (E2EE) सुविधा को जोड़ा जा सकता है. FCM पूरी तरह से खत्म होने की सुविधा नहीं देता. हालांकि, कुछ बाहरी समाधान भी उपलब्ध हैं, जैसे कि Capillary या DTLS.

वैकल्पिक डेटा पेलोड के साथ सूचना वाले मैसेज

प्रोग्राम के हिसाब से या Firebase कंसोल के ज़रिए, दोनों से सूचना वाले ऐसे मैसेज भेजे जा सकते हैं जिनमें कस्टम की-वैल्यू पेयर का वैकल्पिक पेलोड शामिल होता है. सूचनाएं बनाने वाले सेक्शन में, बेहतर विकल्प में कस्टम डेटा फ़ील्ड का इस्तेमाल करें.

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

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

यहां JSON फ़ॉर्मैट में लिखा गया एक मैसेज दिया गया है. इसमें notification कुंजी और data कुंजी, दोनों शामिल हैं:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    },
    "data" : {
      "Nick" : "Mario",
      "Room" : "PortugalVSDenmark"
    }
  }
}

अलग-अलग प्लैटफ़ॉर्म पर मैसेज को पसंद के मुताबिक बनाना

Firebase एडमिन SDK और FCM v1 एचटीटीपी प्रोटोकॉल, दोनों की मदद से आपके मैसेज के अनुरोधों को message ऑब्जेक्ट में उपलब्ध सभी फ़ील्ड सेट करने की अनुमति मिलती है. ऐसे कॉन्टेंट के कुछ उदाहरण यहां दिए गए हैं:

फ़ील्ड का एक सामान्य सेट, जिसे मैसेज पाने वाले सभी ऐप्लिकेशन इंस्टेंस से समझा जा सके.
प्लैटफ़ॉर्म के हिसाब से बने फ़ील्ड, जैसे कि AndroidConfig और WebpushConfig इन्हें सिर्फ़ खास प्लैटफ़ॉर्म पर चल रहे ऐप्लिकेशन इंस्टेंस से समझा जाता है.

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

सामान्य फ़ील्ड का इस्तेमाल कब करें

सामान्य फ़ील्ड का इस्तेमाल तब करें, जब आप:

सभी प्लैटफ़ॉर्म पर ऐप्लिकेशन इंस्टेंस टारगेट करना — Apple, Android, और वेब
विषयों पर मैसेज भेजना

सभी ऐप्लिकेशन इंस्टेंस, प्लैटफ़ॉर्म पर ध्यान दिए बिना, इन सामान्य फ़ील्ड को समझ सकते हैं:

प्लैटफ़ॉर्म के हिसाब से फ़ील्ड का इस्तेमाल कब करना चाहिए

इन कामों के लिए, प्लैटफ़ॉर्म के हिसाब से दिए गए फ़ील्ड इस्तेमाल करें:

सिर्फ़ खास प्लैटफ़ॉर्म पर फ़ील्ड भेजें
सामान्य फ़ील्ड के साथ ही, प्लैटफ़ॉर्म के हिसाब से फ़ील्ड भी भेजें

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

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

उदाहरण: खास प्लैटफ़ॉर्म के हिसाब से डिलीवरी के विकल्पों के साथ सूचना वाला मैसेज

नीचे दिए गए v1 अनुरोध से, सूचना का एक सामान्य टाइटल और कॉन्टेंट सभी प्लैटफ़ॉर्म पर भेजा जाता है. हालांकि, यह प्लैटफ़ॉर्म के हिसाब से कुछ बदलाव भी करता है. खास तौर पर, इस अनुरोध से:

यह Android और वेब प्लैटफ़ॉर्म के लिए लंबे समय तक लाइव जाने की सुविधा को सेट करता है, जबकि एपीएन (Apple प्लैटफ़ॉर्म) मैसेज की प्राथमिकता को कम सेटिंग पर सेट करता है
यह बताने के लिए, Android और Apple — click_action, और category पर उपयोगकर्ता के सूचना पर टैप करने का नतीजा तय करने के लिए, सही कुंजियां सेट करता है.

{
  "message":{
     "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
     "notification":{
       "title":"Match update",
       "body":"Arsenal goal in added time, score is now 3-0"
     },
     "android":{
       "ttl":"86400s",
       "notification"{
         "click_action":"OPEN_ACTIVITY_1"
       }
     },
     "apns": {
       "headers": {
         "apns-priority": "5",
       },
       "payload": {
         "aps": {
           "category": "NEW_MESSAGE_CATEGORY"
         }
       }
     },
     "webpush":{
       "headers":{
         "TTL":"86400"
       }
     }
   }
 }

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

डिलीवरी के विकल्प

FCM, Android डिवाइसों पर भेजे गए मैसेज के लिए डिलीवरी के विकल्पों का एक खास सेट उपलब्ध कराता है. साथ ही, यह Apple प्लैटफ़ॉर्म और वेब पर इसी तरह के विकल्प देता है. उदाहरण के लिए, "छोटा किया जा सकने वाला" मैसेज व्यवहार, FCM के collapse_key से Android पर, Apple पर apns-collapse-id से, और JavaScript/वेब पर Topic से काम करता है. ज़्यादा जानकारी के लिए, इस सेक्शन में दी गई जानकारी और इससे जुड़े दस्तावेज़ देखें.

ऐसे मैसेज जिन्हें छोटा और छोटा नहीं किया जा सकता

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

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

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

छोटा किया जा सकने वाला मैसेज, ऐसा मैसेज होता है जिसे डिवाइस पर डिलीवर न होने के बाद, नए मैसेज से बदला जा सकता है.

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

Android पर किसी मैसेज को छोटा किए जा सकने वाले के तौर पर मार्क करने के लिए, मैसेज के पेलोड में collapse_key पैरामीटर शामिल करें. डिफ़ॉल्ट रूप से, ऐप्लिकेशन के पैकेज का नाम छोटा करें कुंजी होती है. यह नाम 'Firebase कंसोल' में रजिस्टर किया जाता है. FCM सर्वर हर डिवाइस पर एक साथ चार अलग-अलग छोटे किए जा सकने वाले मैसेज सेव कर सकता है. हर मैसेज में, छोटा करने के लिए अलग कुंजी का इस्तेमाल किया जाएगा. अगर आपने इससे ज़्यादा संख्या चुन ली है, तो FCM सिर्फ़ चार छोटा करने वाले बटन सेव करता है. हालांकि, इस बात की कोई गारंटी नहीं होती कि कौनसी कुंजी सेव रहेगी.

बिना पेलोड वाले विषय मैसेज, डिफ़ॉल्ट रूप से छोटे किए जा सकते हैं. सूचना मैसेज हमेशा छोटे किए जा सकते हैं और ये collapse_key पैरामीटर को अनदेखा कर देंगे.

मुझे किसका इस्तेमाल करना चाहिए?

परफ़ॉर्मेंस के हिसाब से, छोटे किए जा सकने वाले मैसेज बेहतर विकल्प होते हैं. हालांकि, यह ज़रूरी नहीं है कि आपके ऐप्लिकेशन में ऐसे मैसेज इस्तेमाल किए जाएं जिन्हें छोटा न किया जा सके. हालांकि, अगर आप छोटे किए जा सकने वाले मैसेज का इस्तेमाल करते हैं, तो FCM किसी भी समय हर रजिस्ट्रेशन टोकन के लिए, ज़्यादा से ज़्यादा चार अलग-अलग छोटा करने वाली कुंजियों का इस्तेमाल करने की अनुमति देता है. आपको इस संख्या से ज़्यादा नहीं होना चाहिए. ऐसा न करने पर, इसकी वजह से गलत नतीजे हो सकते हैं.

	स्थिति का इस्तेमाल करें	कैसे भेजें
न छोटा किया जा सकता है	क्लाइंट ऐप्लिकेशन के लिए हर मैसेज अहम होता है और वह डिलीवर किया जाना चाहिए.	सूचना मैसेज को छोड़कर, सभी मैसेज को डिफ़ॉल्ट रूप से छोटा नहीं किया जा सकता.
छोटा किया जा सकता है	जब क्लाइंट ऐप्लिकेशन के लिए पुराने और मिलते-जुलते मैसेज को रेंडर करने वाला कोई नया मैसेज दिखता है, तो FCM पुराने मैसेज की जगह ले लेता है. उदाहरण के लिए: सर्वर से डेटा सिंक शुरू करने के लिए इस्तेमाल किए जाने वाले मैसेज या पुराने सूचना मैसेज.	मैसेज के अनुरोध में सही पैरामीटर सेट करें: Android पर `collapseKey` Apple पर `apns-collapse-id` वेब पर `Topic` लेगसी प्रोटोकॉल में `collapse_key` (सभी प्लैटफ़ॉर्म पर)

मैसेज की प्राथमिकता सेट करना

डाउनस्ट्रीम मैसेज को डिलीवरी की प्राथमिकता असाइन करने के लिए आपके पास दो विकल्प हैं: सामान्य और ज़्यादा प्राथमिकता. हालांकि, अलग-अलग प्लैटफ़ॉर्म पर यह तरीका थोड़ा अलग होता है, लेकिन सामान्य और ज़्यादा प्राथमिकता वाले मैसेज की डिलीवरी इस तरह से काम करती है:

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

Apple डिवाइसों पर डेटा मैसेज भेजते समय, प्राथमिकता को 5 या सामान्य प्राथमिकता पर सेट किया जाना चाहिए. ज़्यादा प्राथमिकता वाले मैसेज भेजे गए मैसेज को FCM बैकएंड, गड़बड़ी INVALID_ARGUMENT की वजह से अस्वीकार कर देता है.

यहां FCM एचटीटीपी v1 प्रोटोकॉल के ज़रिए भेजे गए, प्राथमिकता वाले सामान्य मैसेज का एक उदाहरण दिया गया है. इसका मकसद, किसी पत्रिका के सदस्य को यह बताना है कि नया कॉन्टेंट डाउनलोड करने के लिए उपलब्ध है:

{
  "message":{
    "topic":"subscriber-updates",
    "notification":{
      "body" : "This week's edition is now available.",
      "title" : "NewsMagazine.com",
    },
    "data" : {
      "volume" : "3.21.15",
      "contents" : "http://www.news-magazine.com/world-week/21659772"
    },
    "android":{
      "priority":"normal"
    },
    "apns":{
      "headers":{
        "apns-priority":"5"
      }
    },
    "webpush": {
      "headers": {
        "Urgency": "high"
      }
    }
  }
}

मैसेज की प्राथमिकता सेट करने के बारे में प्लैटफ़ॉर्म के हिसाब से ज़्यादा जानकारी पाने के लिए:

किसी मैसेज के लिए कितने समय तक मैसेज रखना है, यह सेट करना

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

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

Android और वेब/JavaScript पर, किसी मैसेज को ज़्यादा से ज़्यादा कितने समय तक रखा जा सकता है, यह तय किया जा सकता है. यह वैल्यू 0 से 2,4,19,200 सेकंड (28 दिन) की होनी चाहिए. साथ ही, यह उस ज़्यादा से ज़्यादा समयावधि के बारे में बताती है जिसमें FCM मैसेज सेव करता है और डिलीवर करने की कोशिश करता है. जिन अनुरोधों में यह फ़ील्ड शामिल नहीं होता है, उनके लिए डिफ़ॉल्ट रूप से ज़्यादा से ज़्यादा चार हफ़्ते होते हैं.

इस सुविधा को इस्तेमाल करने के कुछ उदाहरण यहां दिए गए हैं:

वीडियो चैट इनकमिंग कॉल
न्योते के इवेंट की समयसीमा खत्म होने वाली है
कैलेंडर इवेंट

किसी मैसेज की समयसीमा तय करने का एक और फ़ायदा यह भी है कि FCM, 0 सेकंड के टाइम-टू-लाइव वैल्यू वाले मैसेज के लिए, छोटा किए जा सकने वाले मैसेज थ्रॉटलिंग को लागू नहीं करता. FCM उन मैसेज को आसानी से मैनेज करने की कोशिश करता है जिन्हें "अभी या कभी नहीं" डिलीवर करना चाहिए. ध्यान रखें कि time_to_live की वैल्यू 0 होने का मतलब है कि जिन मैसेज को तुरंत डिलीवर नहीं किया जा सकता उन्हें खारिज कर दिया जाता है. हालांकि, इस तरह के मैसेज कभी सेव नहीं किए जाते. इसलिए, सूचना वाले मैसेज भेजने में सबसे ज़्यादा समय लगता है.

यहां एक अनुरोध का उदाहरण दिया गया है, जिसमें TTL (टीटीएल) शामिल है:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    },
    "apns":{
      "headers":{
        "apns-expiration":"1604750400"
      }
    },
    "android":{
      "ttl":"4500s"
    },
    "webpush":{
      "headers":{
        "TTL":"4500"
      }
    }
  }
}

मैसेज कितने समय तक रहेगा

जब कोई ऐप्लिकेशन सर्वर, FCM पर मैसेज पोस्ट करता है और मैसेज आईडी वापस पाता है, तो इसका मतलब यह नहीं है कि मैसेज पहले ही डिवाइस पर डिलीवर कर दिया गया था. इसके बजाय, इसका मतलब है कि उसे डिलीवरी के लिए स्वीकार किया गया था. मैसेज स्वीकार होने के बाद उसका क्या होगा, यह कई बातों पर निर्भर करता है.

सबसे अच्छे मामलों में, अगर डिवाइस FCM से कनेक्ट है, स्क्रीन चालू है और थ्रॉटलिंग से जुड़ी कोई पाबंदी नहीं है, तो मैसेज तुरंत डिलीवर हो जाता है.

अगर डिवाइस कनेक्ट है, लेकिन Doze में है, तो FCM से कम प्राथमिकता वाला एक मैसेज तब तक सेव रखा जाता है, जब तक कि डिवाइस Doze से बाहर नहीं हो जाता. यही वजह है कि collapse_key फ़्लैग एक अहम भूमिका निभाता है: अगर पहले से ही एक मैसेज मौजूद है, जिसमें एक ही छोटा करने वाली कुंजी (और रजिस्ट्रेशन टोकन) मौजूद है और डिलीवरी का इंतज़ार किया जा रहा है, तो पुराना मैसेज खारिज कर दिया जाता है और नया मैसेज अपनी जगह पर ले आता है (इसका मतलब है कि पुराने मैसेज को नए मैसेज से छोटा कर दिया जाएगा). हालांकि, अगर संक्षिप्त करें कुंजी सेट नहीं है, तो नए और पुराने दोनों संदेश भविष्य के वितरण के लिए संग्रहित किए जाते हैं.

अगर डिवाइस FCM से कनेक्ट नहीं है, तो मैसेज तब तक सेव रहता है, जब तक कि कनेक्शन नहीं हो जाता (फिर से छोटा करने के मुख्य नियमों का पालन करें). कोई कनेक्शन बन जाने पर, FCM सभी बचे हुए मैसेज डिवाइस पर डिलीवर करता है. अगर डिवाइस फिर कभी कनेक्ट नहीं होता (उदाहरण के लिए, अगर उसे फ़ैक्ट्री रीसेट किया गया हो), तो मैसेज का समय खत्म हो जाता है और उसे FCM स्टोरेज से खारिज कर दिया जाता है. डिफ़ॉल्ट तौर पर, टाइम आउट चार हफ़्ते का होता है. हालांकि, अगर time_to_live फ़्लैग सेट नहीं है, तो ऐसा किया जा सकता है.

किसी मैसेज की डिलीवरी के बारे में ज़्यादा जानकारी पाने के लिए:

Android या Apple प्लैटफ़ॉर्म पर मैसेज की डिलीवरी के बारे में ज़्यादा अहम जानकारी पाने के लिए, FCM रिपोर्टिंग डैशबोर्ड देखें. यह Apple और Android डिवाइसों पर भेजे गए और खोले गए मैसेज की संख्या के साथ-साथ, Android ऐप्लिकेशन के लिए "इंप्रेशन" (उपयोगकर्ताओं की देखी जाने वाली सूचनाएं) का डेटा भी रिकॉर्ड करता है.

जिन Android डिवाइस में डायरेक्ट चैनल मैसेज सेवा चालू है, अगर डिवाइस एक महीने से ज़्यादा समय से FCM से कनेक्ट नहीं है, तो FCM अब भी मैसेज को स्वीकार करता है, लेकिन उसे तुरंत खारिज कर देता है. अगर डिवाइस, पिछली बार भेजे गए डेटा मैसेज के चार हफ़्तों के अंदर कनेक्ट हो जाता है, तो आपके क्लाइंट को onDeletedMessages() कॉलबैक मिलता है. फिर ऐप्लिकेशन स्थिति को ठीक से संभाल सकता है, आम तौर पर ऐप्लिकेशन सर्वर से पूरी तरह सिंक करने का अनुरोध करके.

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

थ्रॉटलिंग और स्केलिंग

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

छोटा किया जा सकने वाला मैसेज थ्रॉटलिंग

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

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

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

हम छोटे किए जा सकने वाले मैसेज को हर ऐप्लिकेशन में 20 मैसेज तक सीमित करते हैं. साथ ही, हर 3 मिनट में एक मैसेज फिर से भरा जाता है.

XMPP सर्वर थ्रॉटलिंग

FCM XMPP सर्वर से हर प्रोजेक्ट के लिए, हर मिनट ज़्यादा से ज़्यादा 400 कनेक्शन जोड़े जा सकते हैं. हालांकि, हम इस दर को सीमित करते हैं. इसमें मैसेज डिलीवरी की समस्या नहीं होनी चाहिए, लेकिन सिस्टम को स्थिर रखने के लिए यह ज़रूरी है. हर प्रोजेक्ट के लिए, FCM एक साथ 2,500 कनेक्शन की अनुमति देता है.

XMPP की अपस्ट्रीम मैसेज सेवा के लिए, FCM अपस्ट्रीम डेस्टिनेशन सर्वर को ओवरलोड होने से बचाने के लिए, हर प्रोजेक्ट के लिए अपस्ट्रीम मैसेज को 1,500,000/मिनट पर सीमित कर देता है.

ऐप्लिकेशन की खराब परफ़ॉर्मेंस को रोकने के लिए, हम हर डिवाइस पर अपस्ट्रीम मैसेज की सीमा 1,000/मिनट तय करते हैं.

एक डिवाइस पर मैसेज की ज़्यादा से ज़्यादा दर

Android के लिए, एक डिवाइस पर 240 मैसेज/मिनट तक और 5,000 मैसेज/घंटा तक भेजे जा सकते हैं. ज़्यादा थ्रेशोल्ड इसलिए तय किया जाता है, ताकि कम समय के लिए बड़ी संख्या में ट्रैफ़िक मिल सके. जैसे, जब उपयोगकर्ता चैट पर तेज़ी से इंटरैक्ट कर रहे हों. इस सीमा से किसी डिवाइस की बैटरी को अनजाने में खर्च करने की वजह से लॉजिक भेजने में होने वाली गड़बड़ियां नहीं होती हैं.

iOS के लिए, जब दर एपीएन की सीमाओं से ज़्यादा हो जाती है, तो हम गड़बड़ी का मैसेज दिखाते हैं.

विषय संदेश सीमा

विषय की सदस्यता जोड़ने/हटाने की दर, हर प्रोजेक्ट के लिए 3,000 क्यूपीएस तक ही है.

मैसेज भेजने की दरें जानने के लिए, फ़ैनआउट थ्रॉटलिंग देखें.

फ़ैनआउट थ्रॉटलिंग

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

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

एक ही समय में जिन प्रोजेक्ट के लिए फ़ैनआउट का अनुरोध किया गया है उनकी संख्या से तय होता है कि फ़ैनआउट रेट एक ही समय पर हो रहा है. किसी एक प्रोजेक्ट के लिए 10,000 क्यूपीएस की फ़ैनआउट दर बहुत आम है. हालांकि, इसकी कोई गारंटी नहीं है और यह सिस्टम पर कुल लोड होने की वजह से होता है. इस बात पर ध्यान देना ज़रूरी है कि फ़ैनआउट की जो संख्या उपलब्ध है उसे प्रोजेक्ट के हिसाब से बांटा गया है, न कि उन अनुरोधों के लिए. इसलिए, अगर आपके प्रोजेक्ट में दो फ़ैनआउट चल रहे हैं, तो हर एक फ़ैनआउट को फ़ैनआउट की उपलब्ध दर का सिर्फ़ आधा हिस्सा दिखेगा. अपने फ़ैनआउट की स्पीड को बढ़ाने का सुझाव है कि एक बार में सिर्फ़ एक चालू पंखा चालू रखें.

FCM पोर्ट और आपके फ़ायरवॉल

अगर आपके संगठन में इंटरनेट या उससे आने वाले ट्रैफ़िक को सीमित करने के लिए फ़ायरवॉल है, तो आपको इसे कॉन्फ़िगर करना होगा, ताकि आपके नेटवर्क पर मौजूद डिवाइस को मैसेज मिल सकें. इसके लिए, आपको मोबाइल डिवाइस को FCM से कनेक्ट होने देना होगा. आम तौर पर, FCM पोर्ट 5228 का इस्तेमाल करता है. हालांकि, यह कभी-कभी 443, 5229, और 5230 का इस्तेमाल करता है.

आपके नेटवर्क से कनेक्ट होने वाले डिवाइसों के लिए, FCM खास आईपी पते की सुविधा नहीं देता, क्योंकि हमारी आईपी रेंज में बार-बार बदलाव होता है. साथ ही, आपके फ़ायरवॉल के नियम पुराने हो सकते हैं. इससे आपके उपयोगकर्ताओं के अनुभव पर असर पड़ सकता है. आम तौर पर, अनुमति वाले पोर्ट 5228-5230 और 443 पर पोर्ट करें. इसमें आईपी से जुड़ी कोई पाबंदी नहीं होती. हालांकि, अगर आपके पास आईपी से जुड़ी कोई पाबंदी है, तो आपको goog.json में शामिल सभी आईपी पतों को अनुमति वाली सूची में शामिल करना होगा. इस बड़ी सूची को नियमित रूप से अपडेट किया जाता है. साथ ही, आपको सुझाव दिया जाता है कि आप हर महीने अपने नियमों को अपडेट करें. फ़ायरवॉल आईपी की पाबंदियों की वजह से होने वाली समस्याएं, अक्सर कभी-कभी होती हैं. साथ ही, उनकी पहचान करना मुश्किल होता है.

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

खुले टीसीपी पोर्ट:

5228
5229
5230
443

खुलने के लिए होस्टनेम:

mtalk.google.com
mtalk4.google.com
mtalk-staging.google.com
mtalk-dev.google.com
alt1-mtalk.google.com
alt2-mtalk.google.com
alt3-mtalk.google.com
alt4-mtalk.google.com
alt5-mtalk.google.com
alt6-mtalk.google.com
alt7-mtalk.google.com
alt8-mtalk.google.com
android.apis.google.com
device-provisioning.googleapis.com
firebaseinstallations.googleapis.com

नेटवर्क अड्रेस ट्रांसलेशन और/या स्टेटफ़ुल पैकेट इंस्पेक्शन फ़ायरवॉल:

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

वीपीएन इंटरैक्शन और बायपासेबिलिटी

Firebase क्लाउड से मैसेज, यह पक्का करने के लिए कई तरीके अपनाता है कि फ़ोन से सर्वर तक पुश मैसेज सेवा कनेक्शन भरोसेमंद हो और जितनी बार हो सके उतनी बार उपलब्ध हो. वीपीएन का इस्तेमाल करने की वजह से, यह काम और भी मुश्किल हो जाता है.

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

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

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

क्रेडेंशियल

आपने जो FCM सुविधाएं लागू की हैं उनके आधार पर, आपको अपने Firebase प्रोजेक्ट के लिए, नीचे दिए गए क्रेडेंशियल की ज़रूरत पड़ सकती है:

प्रोजेक्ट आईडी	आपके Firebase प्रोजेक्ट के लिए एक यूनीक आइडेंटिफ़ायर, जिसका इस्तेमाल FCM v1 एचटीटीपी एंडपॉइंट के अनुरोधों में किया जाता है. यह वैल्यू Firebase कंसोल सेटिंग पैनल में उपलब्ध है.
रजिस्ट्रेशन टोकन	एक यूनीक टोकन स्ट्रिंग, जो हर क्लाइंट ऐप्लिकेशन इंस्टेंस की पहचान करती है. किसी एक डिवाइस और डिवाइस ग्रुप मैसेज सेवा के लिए, रजिस्ट्रेशन टोकन ज़रूरी है. ध्यान दें कि रजिस्ट्रेशन टोकन को गोपनीय रखा जाना चाहिए.
भेजने वाले का आईडी	Firebase प्रोजेक्ट बनाते समय, अंकों वाली एक यूनीक वैल्यू होती है. यह 'Firebase कंसोल' के सेटिंग पैनल के क्लाउड से मैसेज टैब में उपलब्ध होती है. सेंडर आईडी का इस्तेमाल, हर उस व्यक्ति की पहचान करने के लिए किया जाता है जो क्लाइंट ऐप्लिकेशन पर मैसेज भेज सकता है.
ऐक्सेस टोकन	कुछ समय तक काम करने वाला OAuth 2.0 टोकन, जो एचटीटीपी v1 एपीआई के अनुरोधों को अनुमति देता है. यह टोकन उस सेवा खाते से जुड़ा है जो आपके Firebase प्रोजेक्ट से जुड़ा है. ऐक्सेस टोकन बनाने और उन्हें घुमाने के लिए, अनुरोध भेजने की अनुमति दें में दिया गया तरीका अपनाएं.
सर्वर कुंजी (बंद किए गए लेगसी प्रोटोकॉल के लिए)	एक सर्वर कुंजी जो आपके ऐप्लिकेशन सर्वर को Google की सेवाओं को ऐक्सेस करने की अनुमति देती है. इसमें, बंद Firebase क्लाउड से मैसेज वाले लेगसी प्रोटोकॉल की मदद से मैसेज भेजना शामिल है. अहम जानकारी: अपने क्लाइंट कोड में कहीं भी सर्वर कुंजी शामिल न करें. यह भी पक्का करें कि अपने ऐप्लिकेशन सर्वर को अनुमति देने के लिए, सिर्फ़ सर्वर कुंजियों का इस्तेमाल किया जा रहा हो. FCM, Android, Apple प्लैटफ़ॉर्म, और ब्राउज़र कुंजियों को अस्वीकार कर देता है.