अपडेट करें

POST https://api.pushwoosh.com/messaging/v2/update

पहले से बनाए गए संदेश को, जिसे उसके message_code से पहचाना जाता है, एक नई परिभाषा के साथ बदलता है। यह प्रतिस्थापन एक पूर्ण प्रतिस्थापन है, पैच नहीं: नई परिभाषा ठीक वैसे ही लागू की जाती है जैसे भेजी गई है, और message_code नहीं बदलता है।

अपडेट केवल तभी उपलब्ध होता है जब संदेश अभी भी लंबित हो — भविष्य में भेजने के लिए अनुसूचित हो और अभी तक प्रसंस्करण या डिलीवरी के लिए नहीं उठाया गया हो।

request फ़ील्ड एक पूर्ण Notify परिभाषा है। आपके द्वारा छोड़े गए फ़ील्ड मूल संदेश से नहीं लिए जाते हैं — वे रीसेट हो जाते हैं। पूरा संदेश भेजें जो आप चाहते हैं, न कि केवल बदले हुए हिस्से।
यदि संदेश पहले से ही संसाधित हो रहा है, डिलीवर हो चुका है, रद्द कर दिया गया है, या हटा दिया गया है, तो API 400 लौटाता है। यह कॉल idempotent नहीं है। अपडेट करने से पहले संदेश की स्थिति जांचें।

यह जांचने के लिए कि क्या कोई संदेश अभी भी अपडेट करने योग्य स्थिति में है, संदेश की स्थिति की जाँच करना देखें।

अनुरोध

Authorization: Token <API_TOKEN> हेडर में अपने सर्वर एपीआई टोकन के साथ प्रमाणित करें।

फ़ील्ड	प्रकार	आवश्यक	विवरण
`message_code`	string	हाँ	अपडेट किए जाने वाले संदेश का संदेश कोड, जैसा कि `Notify` द्वारा `result.message_code` में लौटाया गया है।
`request`	object	हाँ	संदेश की पूरी नई परिभाषा। `Notify` अनुरोध बॉडी के समान आकार — एक `segment` या `transactional` ऑब्जेक्ट। `Notify` की तरह ही मान्य किया गया।

उदाहरण अनुरोध

एक सेगमेंट संदेश को फिर से शेड्यूल करें और उसकी सामग्री बदलें:

curl -X POST https://api.pushwoosh.com/messaging/v2/update \
  -H "Authorization: Token YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "message_code": "XXXX-XXXXXXXX-XXXXXXXX",
    "request": {
      "segment": {
        "application": "XXXXX-XXXXX",
        "platforms": ["IOS", "ANDROID"],
        "code": "active_users",
        "payload": {
          "content": {
            "localized_content": {
              "en": {
                "ios":     { "body": "Updated message" },
                "android": { "body": "Updated message" }
              }
            }
          }
        },
        "schedule": { "at": "2026-05-02T12:00:00Z" },
        "message_type": "MESSAGE_TYPE_MARKETING"
      }
    }
  }'

प्रतिक्रिया

सफलता पर, अपडेट किए गए संदेश के परिणाम के साथ HTTP 200 लौटाता है। message_code अपरिवर्तित रहता है।

{
  "result": {
    "message_code": "XXXX-XXXXXXXX-XXXXXXXX",
    "unknown_identifiers": []
  }
}

message_code (string): वही कोड जो अनुरोध में पास किया गया था।
unknown_identifiers (array of string): नई परिभाषा में पहचानकर्ता जो नहीं मिले, जब लागू हो (देखें Notify)।

त्रुटियाँ

त्रुटियाँ मानक gRPC-गेटवे त्रुटि लिफाफे का उपयोग करती हैं: { "code": ..., "message": ..., "details": [...] }।

HTTP स्थिति	शर्त
`400`	`message_code` गुम है।
`400`	नई `request` परिभाषा गुम या अमान्य है (इसे `Notify` की तरह ही मान्य किया जाता है)।
`400`	संदेश अपडेट करने योग्य स्थिति में नहीं है (यह अब `pending` नहीं है)।
`403`	संदेश किसी अन्य खाते का है।
`404`	दिए गए `message_code` के लिए कोई संदेश मौजूद नहीं है।
`500`	संदेश लोड करते समय या अपडेट लागू करते समय एक आंतरिक त्रुटि हुई। अनुरोध को पुनः प्रयास करें।

उदाहरण

एक संदेश को अपडेट करना जो अब मौजूद नहीं है, HTTP 404 लौटाता है:

{
  "code": 5,
  "message": "message not found",
  "details": []
}

संदेश की स्थिति की जाँच करना

अपडेट करने से पहले, आप यह सत्यापित कर सकते हैं कि कोई संदेश अभी भी अपडेट करने योग्य स्थिति में है या नहीं। कंट्रोल पैनल में संदेश तालिका में स्थिति कॉलम पढ़ने के अलावा (अभियान → एक बार के संदेश), आप messages:list के साथ प्रोग्रामेटिक रूप से स्थिति की पूछताछ कर सकते हैं:

filters.messages_codes ऐरे में message_code पास करें (आवश्यक filters.application के साथ)।
items[] में मेल खाने वाली प्रविष्टि के status फ़ील्ड को पढ़ें।