আপডেট

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

পূর্বে তৈরি করা একটি মেসেজকে তার message_code দ্বারা চিহ্নিত করে একটি নতুন সংজ্ঞা দিয়ে প্রতিস্থাপন করে। এই প্রতিস্থাপনটি একটি সম্পূর্ণ প্রতিস্থাপন, কোনো প্যাচ নয়: নতুন সংজ্ঞাটি ঠিক যেমন পাঠানো হয়েছে তেমনই প্রয়োগ করা হয়, এবং message_code পরিবর্তন হয় না।

আপডেট শুধুমাত্র তখনই উপলব্ধ যখন মেসেজটি এখনও পেন্ডিং থাকে — অর্থাৎ ভবিষ্যতের কোনো পাঠানোর জন্য নির্ধারিত এবং এখনও প্রসেসিং বা ডেলিভারির জন্য গৃহীত হয়নি।

request ক্ষেত্রটি একটি সম্পূর্ণ Notify সংজ্ঞা। আপনি যে ক্ষেত্রগুলি বাদ দেবেন সেগুলি মূল মেসেজ থেকে নেওয়া হবে না — সেগুলি রিসেট হয়ে যাবে। আপনি যে সম্পূর্ণ মেসেজটি চান সেটি পাঠান, শুধুমাত্র পরিবর্তিত অংশগুলি নয়।
যদি মেসেজটি ইতিমধ্যে প্রসেসিং-এ থাকে, ডেলিভারি হয়ে গিয়ে থাকে, বাতিল করা হয়ে থাকে, বা মুছে ফেলা হয়ে থাকে, তাহলে API 400 রিটার্ন করে। এই কলটি আইডেম্পোটেন্ট নয়। আপডেট করার আগে মেসেজের স্ট্যাটাস পরীক্ষা করুন।

একটি মেসেজ এখনও আপডেটযোগ্য অবস্থায় আছে কিনা তা পরীক্ষা করতে, দেখুন মেসেজের স্ট্যাটাস পরীক্ষা করা।

অনুরোধ

আপনার সার্ভার API টোকেন দিয়ে 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-Gateway এরর এনভেলপ ব্যবহার করে: { "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": []
}

মেসেজের স্ট্যাটাস পরীক্ষা করা

আপডেট করার আগে, আপনি যাচাই করতে পারেন যে একটি মেসেজ এখনও আপডেটযোগ্য অবস্থায় আছে কিনা। কন্ট্রোল প্যানেলের মেসেজ টেবিলে স্ট্যাটাস কলামটি পড়া ছাড়াও (Campaigns → One-time messages), আপনি messages:list ব্যবহার করে প্রোগ্রাম্যাটিকভাবে স্ট্যাটাস কোয়েরি করতে পারেন:

filters.messages_codes অ্যারেতে message_code পাস করুন (প্রয়োজনীয় filters.application-এর সাথে)।
items[]-এ ম্যাচিং এন্ট্রির status ক্ষেত্রটি পড়ুন।