নোটিফাই

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

একটি একক বার্তা তৈরি এবং সময়সূচী করে।

রিকোয়েস্ট স্ট্রাকচার

রিকোয়েস্ট বডি একটি NotifyRequest যা দুটি ধরণের মধ্যে ঠিক একটি:

• segment: সেগমেন্ট কোড দ্বারা একটি অডিয়েন্স সেগমেন্টকে টার্গেট করুন, অথবা — প্রথমে একটি সেগমেন্ট তৈরি না করে — একটি seglang এক্সপ্রেশন বা একটি স্ট্রাকচার্ড ফিল্টার এক্সপ্রেশন ব্যবহার করুন।
• transactional: hwids, ইউজার আইডি, পুশ টোকেন, বা টেস্ট ডিভাইসের একটি সুস্পষ্ট তালিকায় পাঠান।

Shape

{
  "segment": { ... },      // OR
  "transactional": { ... },
  "transaction_id": "unique-uuid"
}

ফিল্ড	টাইপ	বর্ণনা
transaction_id	string	ঐচ্ছিক। রিকোয়েস্টের জন্য আইডমপোটেন্সি কী — segment এবং transactional উভয়ের সাথে কাজ করে। ৫ মিনিটের মধ্যে একই transaction_id দিয়ে পুনরায় কল করলে ডুপ্লিকেট বার্তা পাঠানোর পরিবর্তে আসল message_code ফেরত আসে। একটি UUID বা প্রতি লজিক্যাল সেন্ডের জন্য একটি অনন্য মান ব্যবহার করুন।

টিপ

এন্ড-টু-এন্ড ট্রেসিংয়ের জন্য আপনার রিকোয়েস্টের সাথে তৈরি করা বার্তাটি কোরিলেট করতে একটি X-Request-ID হেডার পাস করুন — দেখুন রিকোয়েস্ট আইডি।

শুধুমাত্র কী চেক করা হয়, পেলোড নয়

ডিডুপ্লিকেশন শুধুমাত্র transaction_id-এর উপর ভিত্তি করে ম্যাচ করে। যদি একটি রিট্রাই একই transaction_id পুনরায় ব্যবহার করে কিন্তু একটি ভিন্ন segment / transactional বডি পাঠায়, তাহলেও আসল message_code ফেরত দেওয়া হয় এবং নতুন বডিটি নীরবে বাতিল করা হয় — এটি প্রথম রিকোয়েস্টের সাথে তুলনা করা হয় না। যৌক্তিকভাবে ভিন্ন বার্তাগুলির মধ্যে কখনও একটি transaction_id পুনরায় ব্যবহার করবেন না।

টিপ

এটি লিগ্যাসি মেসেজেস এপিআই-এর transactionId-এর মতো একই ডিডুপ্লিকেশন মেকানিজম, যা একই ৫-মিনিটের স্টোরেজ উইন্ডো শেয়ার করে, তাই একটি রিট্রাই করা রিকোয়েস্ট /createMessage এবং Notify উভয়ের মধ্যে ডিডুপ্লিকেট করা হয়। এটি PW_Conversion রেভিনিউ ইভেন্টের transaction_id অ্যাট্রিবিউটের সাথে সম্পর্কিত নয়, যা Pushwoosh যেমন আছে তেমন সঞ্চয় করে এবং ডিডুপ্লিকেশনের জন্য ব্যবহার করে না।

NotifySegment

যেসব ব্যবহারকারী একটি অডিয়েন্স সেগমেন্ট বা ফিল্টার এক্সপ্রেশনের সাথে মেলে তাদের টার্গেট করে। code, expression, বা filter_expression-এর মধ্যে ঠিক একটি সেট করুন। expression এবং filter_expression-এর জন্য, আগে থেকে কোনো সেগমেন্ট তৈরি করার প্রয়োজন নেই — এক্সপ্রেশনটি শুধুমাত্র এই সেন্ডের জন্য ইনলাইন মূল্যায়ন করা হয়।

কোড এবং ইনলাইন এক্সপ্রেশনের মধ্যে নির্বাচন

শুধুমাত্র code দ্বারা রেফারেন্স করা একটি সেভ করা সেগমেন্ট হাই-স্পিড ডেলিভারি প্রি-কম্পাইলেশন ব্যবহার করতে পারে। expression এবং filter_expression পাঠানোর সময় মূল্যায়ন করা হয় এবং কখনও প্রি-কম্পাইল করা হয় না।

ফিল্ড	টাইপ	বর্ণনা
schedule	Schedule	কখন এবং কিভাবে পাঠাতে হবে। আবশ্যক।
application	string	অ্যাপ্লিকেশন কোড।
platforms	array of Platform	যেসব প্ল্যাটফর্মে বার্তাটি টার্গেট করা হয়েছে।
code	string	আগে থেকে সেভ করা একটি সেগমেন্টের সেগমেন্ট কোড। expression এবং filter_expression-এর সাথে পারস্পরিকভাবে এক্সক্লুসিভ।
expression	string	Seglang এক্সপ্রেশন, শুধুমাত্র এই সেন্ডের জন্য মূল্যায়ন করা হয় — কোনো সেভ করা সেগমেন্টের প্রয়োজন নেই। code এবং filter_expression-এর সাথে পারস্পরিকভাবে এক্সক্লুসিভ।
filter_expression	FilterExpression	expression-এর মতো একই লজিক, একটি seglang স্ট্রিং-এর পরিবর্তে একটি স্ট্রাকচার্ড অবজেক্ট হিসাবে। code এবং expression-এর সাথে পারস্পরিকভাবে এক্সক্লুসিভ। FilterExpression স্কিমা সর্বজনীনভাবে নথিভুক্ত নয় — যদি আপনার স্ট্রাকচার্ড ফর্মের প্রয়োজন হয় তবে Pushwoosh সাপোর্ট থেকে এটি অনুরোধ করুন।
payload	Payload	পুশ / SMS / টেলিগ্রাম / Kakao / LINE / WhatsApp / Viber / Facebook Messenger পেলোড। email_payload-এর সাথে পারস্পরিকভাবে এক্সক্লুসিভ।
email_payload	EmailPayload	ইমেল পেলোড।
campaign	string	এই বার্তাটিকে অ্যাট্রিবিউট করার জন্য ক্যাম্পেইন কোড।
campaign_name	string	এই বার্তাটির অভ্যন্তরীণ নাম, যা Message History-এ সারির শিরোনাম হিসেবে এবং এর এক্সপোর্টে দেখানো হয়। উপরের campaign-এর সাথে এর কোনো সম্পর্ক নেই। এটি বার্তা গ্রুপ করে না বা ডেলিভারি প্রভাবিত করে না। সর্বোচ্চ ২৫৫ অক্ষর, ছাঁটা হয়। এটি বাদ দিন বা খালি রাখুন, যাতে সারির শিরোনাম পেলোডের নিজস্ব কনটেন্ট থেকে আসে।
frequency_capping	FrequencyCapping	প্রতি-ব্যবহারকারী ফ্রিকোয়েন্সি সীমা।
send_rate	SendRate	সেন্ডের জন্য থ্রটলিং।
silent_hours	SilentHours	ঐচ্ছিক। অ্যাপ্লিকেশনের সাইলেন্ট আওয়ার উপেক্ষা করে মেসেজ পাঠায়।
message_type	MessageType	MESSAGE_TYPE_MARKETING (ডিফল্ট) বা MESSAGE_TYPE_TRANSACTIONAL। কন্ট্রোল-গ্রুপ ফিল্টারিং নিয়ন্ত্রণ করে।
dynamic_content_placeholders	map<string, string>	কন্টেন্টে প্লেসহোল্ডার প্রতিস্থাপন করে।
meta_data	object	ডাউনস্ট্রিম অ্যানালিটিক্সে ফরোয়ার্ড করা ফ্রি-ফর্ম মেটাডেটা।
use_latest_user_device	bool	যখন true, তখন বার্তাটি প্রতিটি ব্যবহারকারীর সবচেয়ে সম্প্রতি সক্রিয় ডিভাইসে (সর্বশেষ Last Application Open সহ ডিভাইস) পৌঁছে দেয়, সেগমেন্ট দ্বারা ম্যাচ করা প্রতিটি ডিভাইসের পরিবর্তে। platforms-এ স্কোপ করা: শুধুমাত্র সেই প্ল্যাটফর্মের ডিভাইসগুলি বিবেচনা করা হয়, এবং যদি কোনোটিতে Last Application Open ডেটা না থাকে, তাহলে সেন্ড ড্রপ করার পরিবর্তে প্রথম ম্যাচিং ডিভাইসটি ব্যবহার করা হয়। ডিফল্ট false (প্রতিটি ডিভাইসে পাঠান)।
geo_zone	GeoZone	ঐচ্ছিক। অডিয়েন্সকে সেইসব ডিভাইসে সীমিত করে, যাদের সর্বশেষ রেকর্ড করা অবস্থান এই রিকোয়েস্টে আপনার নির্ধারিত একটি বৃত্তের ভিতরে আছে। এটি code, expression, বা filter_expression-এর সাথে AND দ্বারা যুক্ত হয়: একটি ডিভাইসকে সেগমেন্টের সাথে মিলতে হবে এবং বৃত্তের ভিতরে থাকতে হবে। কোনো রেকর্ড করা অবস্থান নেই এমন ডিভাইসগুলি বাদ দেওয়া হয়। NotifyTransactional-এ উপলব্ধ নয়।
control_group	string	এই বার্তায় প্রয়োগ করার জন্য সেন্ডের নিজস্ব হোল্ড-আউট গ্রুপের কোড বা নাম। এটি কোন কন্ট্রোল গ্রুপ প্রযোজ্য হবে তা সীমিত করে না: ফিল্ডটি সেট করা থাকুক বা না থাকুক, অ্যাপ্লিকেশনের প্রতিটি সক্রিয় কন্ট্রোল গ্রুপ মার্কেটিং সেন্ড থেকে ব্যবহারকারীদের হোল্ড আউট করে। holdout_percentage-এর সাথে একসাথে ব্যবহার করা যায় না।
holdout_percentage	uint32	সেগমেন্টের এই অংশ (1–20) অ্যাপ্লিকেশনের সক্রিয় কন্ট্রোল গ্রুপগুলির পাশাপাশি শুধু এই সেন্ডের জন্য সীমিত একটি কন্ট্রোল গ্রুপে টেনে নেয়, যাতে শেয়ার করা কন্ট্রোল গ্রুপগুলি খরচ না করেই একটি একক ক্যাম্পেইনের প্রভাব পরিমাপ করা যায়। 0 (ডিফল্ট) এটি বন্ধ রাখে। control_group-এর সাথে একসাথে ব্যবহার করা যায় না।

গুরুত্বপূর্ণ

Pushwoosh হোল্ডআউট গ্রুপটির নাম দেয় __holdout_<campaign code> (অথবা campaign ছাড়া কোনো সেন্ডের ক্ষেত্রে __holdout_<message code>) এবং একই কোড ব্যবহারকারী পরবর্তী প্রতিটি সেন্ডে সেই একই গ্রুপটি তার মূল শতাংশে আবার ব্যবহার করে। গ্রুপটি প্রথমবার তৈরি হওয়ার সময়েই নির্বাচন স্থির হয়ে যায়। এই গ্রুপটি কখনও সেটিংস > কন্ট্রোল গ্রুপ-এ দেখা যায় না, এবং এর আকার পরিবর্তন, পুনরায় শাফল, নিষ্ক্রিয় বা মুছে ফেলার চেষ্টা করলে FailedPrecondition ফেরত আসে, কারণ পরিমাপের মাঝখানে এটি পরিবর্তন করলে তুলনাটি অকার্যকর হয়ে যাবে।

হোল্ডআউটে টেনে নেওয়া ডিভাইসগুলি অ্যাপ্লিকেশনের কন্ট্রোল গ্রুপ যেভাবে বাদ দেয়, ঠিক সেভাবেই ডেলিভারি থেকে বাদ পড়ে। তাদের কাছে বার্তা পাঠানো হয় না, এবং ট্র্যাকিং লগ এই বাদ পড়াটিকে Device is in control group হিসেবে রেকর্ড করে। MESSAGE_TYPE_TRANSACTIONAL মানের message_type এই বাদ দেওয়া সম্পূর্ণভাবে এড়িয়ে যায়, ঠিক যেমন অ্যাপ্লিকেশনের কন্ট্রোল গ্রুপগুলির ক্ষেত্রে হয়।

holdout_percentage-কে control_group-এর সাথে একসাথে সেট করলে, অথবা 20-এর বেশি holdout_percentage দিলে, 400 ফেরত আসে:

Invalid holdout_percentage

{
  "code": 3,
  "message": "invalid argument",
  "details": [
    {
      "@type": "type.googleapis.com/google.rpc.BadRequest",
      "fieldViolations": [
        {
          "field": "holdout_percentage",
          "description": "holdout_percentage and control_group are mutually exclusive"
        }
      ]
    },
    {
      "@type": "type.googleapis.com/google.rpc.ErrorInfo",
      "reason": "InvalidHoldoutPercentage",
      "domain": "api.pushwoosh.com",
      "metadata": {}
    }
  ]
}

উদাহরণ: একটি সেগমেন্টে পাঠান

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

NotifyTransactional

প্রাপকদের একটি সুস্পষ্ট তালিকায় পাঠায়।

ফিল্ড	টাইপ	বর্ণনা
schedule	Schedule	আবশ্যক।
application	string	অ্যাপ্লিকেশন কোড।
platforms	array of Platform	যেসব প্ল্যাটফর্মে বার্তাটি টার্গেট করা হয়েছে।
test_devices	bool	যদি true হয়, শুধুমাত্র অ্যাপের টেস্ট ডিভাইসগুলিতে পাঠান।
hwids	{ "list": [string, ...] }	শুধুমাত্র এই hwids-এ পাঠান।
users	{ "list": [string, ...] }	শুধুমাত্র এই ইউজার আইডি-তে পাঠান।
push_tokens	{ "list": [string, ...] }	শুধুমাত্র এই পুশ টোকেন-এ পাঠান।
payload	Payload	পুশ / SMS / টেলিগ্রাম / Kakao / LINE / WhatsApp / Viber / Facebook Messenger পেলোড।
email_payload	EmailPayload	ইমেল পেলোড।
return_unknown_identifiers	bool	যখন true, তখন রেসপন্সের unknown_identifiers তালিকায় এমন আইডেন্টিফায়ারগুলো থাকে যা পাওয়া যায়নি।
registration_type	RegistrationType	যেসব hwids এখনও Pushwoosh-এ রেজিস্টার করা হয়নি, সেগুলির ক্ষেত্রে কী করা হবে। ডিফল্ট REGISTRATION_TYPE_DEFAULT, যা সেগুলি বাদ দেয়। একই রিকোয়েস্টে নতুন ইমেল ঠিকানা বা ফোন নম্বর রেজিস্টার করে সেগুলিতে পাঠাতে REGISTRATION_TYPE_FORCE সেট করুন।
use_latest_user_device	bool	শুধুমাত্র যখন আপনি users-কে টার্গেট করেন তখন প্রযোজ্য। উপরের NotifySegment-এর মতো একই আচরণ — প্রতি ডিভাইসের পরিবর্তে প্রতি ব্যবহারকারী একটি বার্তা পৌঁছে দেয়, platforms-এ স্কোপ করা। ডিফল্ট false।
campaign, campaign_name, frequency_capping, send_rate, silent_hours, message_type, dynamic_content_placeholders, meta_data		উপরে NotifySegment দেখুন।

test_devices, hwids, users, এবং push_tokens পারস্পরিকভাবে এক্সক্লুসিভ। ঠিক একটি সেট করতে হবে।

নতুন ইমেল ঠিকানা এবং ফোন নম্বরে পাঠানো

ইমেল, SMS, WhatsApp, LINE, Viber, এবং Kakao-র ক্ষেত্রে hwid নিজেই গন্তব্য, যেমন ইমেল ঠিকানা বা ফোন নম্বর। এখনও রেজিস্টার করা হয়নি এমন একটি hwid-এ পাঠাতে, এটি hwids-এ তালিকাভুক্ত করুন এবং registration_type-কে REGISTRATION_TYPE_FORCE-এ সেট করুন। Pushwoosh একই রিকোয়েস্টে এটি রেজিস্টার করে এবং বার্তাটি পৌঁছে দেয়, তাই আগে আলাদা /registerDevice বা /registerEmail কলের প্রয়োজন নেই।

registration_type শুধুমাত্র hwids-এর সাথে কাজ করে। users-এর ক্ষেত্রে, registration_type যা-ই সেট করা থাকুক, অজানা ইউজার আইডি তৈরি করা হয় না।

প্রতিটি hwid সেই চ্যানেলের জন্য /registerDevice যে ফরম্যাটে সংরক্ষণ করে, সেই একই ফরম্যাটে লিখুন:

চ্যানেল	hwid ফরম্যাট	উদাহরণ
ইমেল	ইমেল ঠিকানা	new.customer@example.com
SMS	আন্তর্জাতিক ফরম্যাটে ফোন নম্বর	+14155552671
WhatsApp	whatsapp: প্রিফিক্স সহ ফোন নম্বর	whatsapp:+14155552671
Kakao	kakao: প্রিফিক্স সহ ফোন নম্বর	kakao:+821012345678
Viber	viber: প্রিফিক্স সহ ফোন নম্বর। প্রিফিক্স না থাকলে Pushwoosh তা যোগ করে	viber:+14155552671
LINE	LINE ইউজার আইডি	U4af4980629a1b2c3d4e5f6a7b8c9d0e1

whatsapp: এবং kakao: প্রিফিক্স রাখুন। এগুলি ছাড়া নম্বরটি একটি SMS hwid হিসেবে পড়া হয়। যদি সেই নম্বরটি ইতিমধ্যে SMS-এর জন্য রেজিস্টার করা থাকে, তাহলে সেন্ডটি SMS hwid খুঁজে পায়, যা টার্গেট করা প্ল্যাটফর্মের সাথে মেলে না, এবং প্রাপককে বাদ দেওয়া হয়।

Pushwoosh শুধুমাত্র return_unknown_identifiers: true থাকলে ফোন নম্বর যাচাই করে। তখন যে SMS, WhatsApp, বা Kakao hwid একটি বৈধ ফোন নম্বর নয়, সেটি রেজিস্টার করা হয় না এবং unknown_identifiers-এ ফিরে আসে। এই ফ্ল্যাগ ছাড়া মানটি যেমন আছে তেমনই রেজিস্টার করা হয়।

REGISTRATION_TYPE_FORCE পুশ প্ল্যাটফর্ম, Telegram, বা Facebook Messenger-এ hwid রেজিস্টার করে না, কারণ এগুলির জন্য SDK বা মেসেঞ্জার থেকে একটি টোকেন প্রয়োজন। এসব প্ল্যাটফর্মে অজানা hwid নীরবে বাদ দেওয়া হয়। এটি unknown_identifiers-এ ফিরে আসে না, এবং এতে কিছুই পাঠানো হয় না।

WhatsApp-এর ক্ষেত্রে, একটি নম্বর রেজিস্টার করলে 24-ঘণ্টার কাস্টমার সার্ভিস উইন্ডো খোলে না। যে নম্বর আপনাকে বার্তা পাঠায়নি, সেটি শুধুমাত্র whatsapp.content_id-এ সেট করা একটি পূর্ব-অনুমোদিত টেমপ্লেট পেতে পারে, ফ্রি-ফর্ম whatsapp.content নয়।

উদাহরণ: একটি নতুন ইমেল ঠিকানায় পাঠানো

curl -X POST https://api.pushwoosh.com/messaging/v2/notify \
  -H "Authorization: Token YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "transactional": {
      "application": "XXXXX-XXXXX",
      "platforms": ["EMAIL"],
      "hwids": { "list": ["new.customer@example.com"] },
      "registration_type": "REGISTRATION_TYPE_FORCE",
      "email_payload": {
        "subject": { "en": "Welcome aboard" },
        "body": "<p>Thanks for signing up!</p>"
      },
      "schedule": { "at": "2026-05-01T12:00:00Z" },
      "message_type": "MESSAGE_TYPE_TRANSACTIONAL",
      "return_unknown_identifiers": true
    }
  }'

উদাহরণ: ইউজার আইডি দ্বারা ট্রানজ্যাকশনাল

curl -X POST https://api.pushwoosh.com/messaging/v2/notify \
  -H "Authorization: Token YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "transactional": {
      "application": "XXXXX-XXXXX",
      "platforms": ["IOS", "ANDROID"],
      "users": { "list": ["user-123", "user-456"] },
      "payload": {
        "content": {
          "localized_content": {
            "en": { "ios": { "body": "Your order has shipped." } }
          }
        }
      },
      "schedule": { "at": "2026-05-01T12:00:00Z" },
      "message_type": "MESSAGE_TYPE_TRANSACTIONAL",
      "return_unknown_identifiers": true,
      "use_latest_user_device": true
    }
  }'

রেসপন্স

{
  "result": {
    "message_code": "XXXXX-XXXXX-XXXXX",
    "unknown_identifiers": []
  }
}

ফিল্ড	টাইপ	বর্ণনা
message_code	string	অনন্য মেসেজ কোড। এটি /getMessageDetails এবং মেসেজ পরিসংখ্যান এন্ডপয়েন্টের সাথে ব্যবহার করুন।
unknown_identifiers	array of string	অ্যাকাউন্টে পাওয়া যায়নি এমন আইডেন্টিফায়ার। শুধুমাত্র return_unknown_identifiers: true সহ বা push_tokens টার্গেটিং সহ একটি transactional সেন্ডের ক্ষেত্রে পপুলেট করা হয়। REGISTRATION_TYPE_FORCE-এর মাধ্যমে রেজিস্টার করা আইডেন্টিফায়ারগুলি তালিকাভুক্ত হয় না।

১০ জনের কম ব্যবহারকারী এবং ১০টির কম ডিভাইসে তাৎক্ষণিকভাবে পাঠানো transactional মেসেজ /getMessageDetails খুঁজে পায় না, কারণ এমন মেসেজ সংরক্ষিত হয় না। দেখুন ১০ জনের কম প্রাপককে তাৎক্ষণিকভাবে পাঠানো মেসেজ।

কোনো প্রাপক পাওয়া যায়নি

return_unknown_identifiers: true বা push_tokens টার্গেটিং থাকলে, Pushwoosh বার্তা তৈরি করার আগে প্রতিটি প্রাপক খুঁজে দেখে। যদি তাদের কেউই রেজিস্টার করা না থাকে, Notify এই ত্রুটিসহ HTTP 400 ফেরত দেয়, এবং কোনো বার্তা তৈরি হয় না:

{
  "code": 9,
  "message": "No recipients found",
  "details": [ ... ]
}

অন্তত একজন প্রাপক পাওয়া গেলে রিকোয়েস্টটি সফল হয় এবং বাকিগুলি unknown_identifiers-এ তালিকাভুক্ত হয়। এর পরিবর্তে নতুন ইমেল ঠিকানা বা ফোন নম্বরে পাঠাতে, registration_type-কে REGISTRATION_TYPE_FORCE-এ সেট করুন।

ইমেলের ক্ষেত্রে, অবৈধ ঠিকানা এবং আগে বাউন্স হওয়া ঠিকানাগুলি এই যাচাইয়ের আগেই সরিয়ে দেওয়া হয়, unknown_identifiers-এ তালিকাভুক্ত না করে। এরপর কোনো ঠিকানা না থাকলে, Notify একটি message_code সহ 200 ফেরত দেয়, কিন্তু কোনো বার্তা তৈরি হয় না এবং কিছুই পাঠানো হয় না।

শেয়ার্ড টাইপ

Schedule

{
  "at": "2026-05-01T12:00:00Z",
  "follow_user_timezone": true,
  "past_timezones_behaviour": "PAST_TIMEZONES_BEHAVIOUR_SEND_IMMEDIATELY"
}

ফিল্ড	টাইপ	বর্ণনা
at	timestamp	পরম পাঠানোর সময় (RFC 3339)। ভবিষ্যতে সর্বোচ্চ 30 দিন। follow_user_timezone সেট করা না থাকলে বা false হলে, অতীতের at-এর জায়গায় রিকোয়েস্ট পাওয়ার সময় বসানো হয়, তাই বার্তাটি সবার কাছে অবিলম্বে চলে যায়। follow_user_timezone: true হলে অতীতের at যেমন আছে তেমনই রাখা হয়। নিচের সতর্কতা দেখুন।
after	duration	at-এর বিকল্প। “এখন” থেকে এই অফসেটের পরে পাঠান (যেমন "3600s")। সর্বোচ্চ 30 দিন।
follow_user_timezone	bool	যখন true, প্রতিটি ডিভাইস তার স্থানীয় টাইমজোনে at সময়ে বার্তাটি গ্রহণ করে।
past_timezones_behaviour	enum	PAST_TIMEZONES_BEHAVIOUR_SEND_IMMEDIATELY (ডিফল্ট), PAST_TIMEZONES_BEHAVIOUR_DO_NOT_SEND, বা PAST_TIMEZONES_BEHAVIOUR_NEXT_DAY। শুধুমাত্র যখন follow_user_timezone true হয় অথবা best_time_to_send সেট করা থাকে তখন অর্থপূর্ণ।
best_time_to_send	timestamp	ঐচ্ছিক। শুধু সেগমেন্ট সেন্ডের জন্য। প্রতিটি ডিভাইস এই সময় থেকে 24 ঘণ্টার মধ্যে তার নিজস্ব সেরা ঘণ্টায় বার্তাটি পায়। যেসব ডিভাইসের কোনো সেরা ঘণ্টা নেই, সেগুলি তাদের স্থানীয় টাইমজোনে at / after-এর তারিখ ও সময়ে এটি পায়। পাঠানোর সেরা সময় দেখুন।

follow_user_timezone থাকলে অতীতের সেন্ড টাইম সবার জন্য তাৎক্ষণিক নয়

follow_user_timezone: true হলে অতীতের at “এখন”-এ সরানো হয় না। এর UTC তারিখ ও সময় তখনও প্রতিটি ডিভাইসের স্থানীয় সময়ের স্লটে ভাগ হয়। যেসব টাইমজোনে সেই স্থানীয় সময় এখনও আসেনি, সেগুলি বার্তাটি সেই সময়ে পায়। যেসব টাইমজোনে তা ইতিমধ্যে পেরিয়ে গেছে, সেগুলি past_timezones_behaviour অনুসরণ করে: এখনই পাঠানো, বাদ দেওয়া (DO_NOT_SEND), অথবা একই স্থানীয় সময়ে এক দিন পিছিয়ে দেওয়া (NEXT_DAY)। best_time_to_send-এর ফলব্যাকের ক্ষেত্রেও একই ভাগ প্রযোজ্য।

পাঠানোর সেরা সময়

best_time_to_send হলো Control Panel-এর সেরা সময় অপশনের API সমতুল্য। at / after সেই ডিভাইসগুলির জন্য ফলব্যাক নির্ধারণ করে, যাদের সেরা ঘণ্টা নির্ধারণের মতো যথেষ্ট ডেটা নেই। Pushwoosh at / after-এর UTC তারিখ ও সময় নেয় এবং প্রতিটি ডিভাইসের স্থানীয় টাইমজোনে সেই তারিখ ও সময়ে ফলব্যাক ডেলিভার করে, যেমনটি follow_user_timezone: true-এর ক্ষেত্রে হয়। এটি অন্তর্নিহিতভাবে প্রযোজ্য হয়: follow_user_timezone সেট না করে রাখুন, কারণ true হলে BestTimeToSendWithUserTimezone সহ প্রত্যাখ্যান করা হয়। নিচের উদাহরণে, সেরা ঘণ্টা নেই এমন ডিভাইসগুলি 1 মে স্থানীয় সময় 18:00-এ বার্তাটি পায়। যেখানে সেন্ড শুরু হওয়ার সময় সেই স্থানীয় সময় ইতিমধ্যে পেরিয়ে গেছে, সেখানে past_timezones_behaviour প্রযোজ্য হয়।

{
  "at": "2026-05-01T18:00:00Z",
  "best_time_to_send": "2026-05-01T00:00:00Z"
}

নিচের সবগুলি শর্ত পূরণ না হলে Pushwoosh রিকোয়েস্টটি 400 দিয়ে প্রত্যাখ্যান করে:

• রিকোয়েস্টটি segment ধরন ব্যবহার করে। transactional সেন্ড best_time_to_send সমর্থন করে না।
• follow_user_timezone সেট করা নেই বা false।
• at / after থেকে পাওয়া সেন্ড টাইম ভবিষ্যতে। অতীতের at, after: "0s", বা বাদ দেওয়া after “এখনই পাঠান” হিসেবে গণ্য হয় এবং প্রত্যাখ্যাত হয়।
• best_time_to_send পরবর্তী পূর্ণ ঘণ্টার আগে নয় এবং 30 দিনের বেশি পরে নয়। এটিকে নিচের দিকে পূর্ণ ঘণ্টায় রাউন্ড করা হয়।
• at / after থেকে পাওয়া সেন্ড টাইম best_time_to_send যোগ 24 ঘণ্টার পরে নয়।

ত্রুটির reason (ErrorInfo বিবরণে) ব্যর্থ হওয়া চেকটির নাম জানায়:

reason	কারণ
BestTimeToSendWithUserTimezone	follow_user_timezone হলো true।
BestTimeToSendTooEarly	best_time_to_send পরবর্তী পূর্ণ ঘণ্টার আগে।
BestTimeToSendTooFarInFuture	best_time_to_send 30 দিনের বেশি পরে।
SendDateAfterBestTimeToSend	at / after হলো best_time_to_send যোগ 24 ঘণ্টার পরে।
BestTimeToSendNotAllowed	একটি transactional সেন্ডে best_time_to_send সেট করা হয়েছে।
BestTimeToSendWithSendNow	at / after “এখন” হিসেবে নির্ধারিত হয় (অতীতের at বা শূন্য after)।

GeoZone

geo_zone-এর জন্য একবারের একটি বৃত্ত, যা রিকোয়েস্টেই নির্ধারণ করা হয়। এটি কোনো সেভ করা জিওজোন নয়: জিও ক্যাম্পেইন এবং Geozones API এতে জড়িত নয়, এবং অ্যাপ্লিকেশনে কিছুই সংরক্ষণ করা হয় না।

{ "lat": 40.7128, "lng": -74.006, "range": 500 }

ফিল্ড	টাইপ	বর্ণনা
lat	double	বৃত্তের কেন্দ্রের অক্ষাংশ, ডিগ্রিতে। আবশ্যক।
lng	double	বৃত্তের কেন্দ্রের দ্রাঘিমাংশ, ডিগ্রিতে। আবশ্যক।
range	double	মিটারে বৃত্তের ব্যাসার্ধ। আবশ্যক।

সতর্কতা

API এই মানগুলি যাচাই করে না। বাদ দেওয়া ফিল্ড 0 হিসেবে পড়া হয়, এবং সীমার বাইরের lat / lng বা 0 মানের range প্রত্যাখ্যান করা হয় না। এমন সেন্ড একটি মেসেজ কোড সহ গৃহীত হয় কিন্তু 400 ফেরত দেওয়ার পরিবর্তে খুব কম ডিভাইসের সাথে মেলে বা কোনোটির সাথেই মেলে না।

FrequencyCapping

মার্কেটিং সেন্ডের জন্য প্রতি-ব্যবহারকারী ফ্রিকোয়েন্সি সীমা। ক্যাপিং নিষ্ক্রিয় করতে, frequency_capping সম্পূর্ণভাবে বাদ দিন, অথবা days: 0 এবং count: 0 একসাথে পাঠান।

{ "days": 7, "count": 3, "exclude": false, "avoid": true }

• days (int, 1–30, বা 0 ক্যাপিং নিষ্ক্রিয় করতে): লুক-ব্যাক উইন্ডো। অবশ্যই count-এর সাথে একসাথে পাঠাতে হবে — যদি একটি 0 হয়, অন্যটিও 0 হতে হবে; একটি 0 এবং অন্যটি নন-জিরো পাঠালে 400 ফেরত আসে।
• count (int, 1 বা তার বেশি, বা 0 ক্যাপিং নিষ্ক্রিয় করতে): days-এর মধ্যে অনুমোদিত সর্বোচ্চ বার্তা। উপরের days-এর মতো একই পেয়ারিং নিয়ম।
• exclude (bool): যারা ইতিমধ্যে ক্যাপে পৌঁছেছে তাদের হার্ড-এক্সক্লুড করুন।
• avoid (bool): যারা ইতিমধ্যে ক্যাপে পৌঁছেছে তাদের সফট-এভয়েড করুন (তারা এখনও অ্যানালিটিক্সের জন্য গণনা করা হয়)।

গুরুত্বপূর্ণ

days এবং count অমিল শূন্যতা সহ (যেমন {"days": 0, "count": 5}) পাঠালে 400 ফেরত আসে। এই ভ্যালিডেশনটি Notify-এর জন্য একটি ব্রেকিং চেঞ্জ — যে ক্লায়েন্টরা আগে একটি একাকী 0 নীরবে উপেক্ষা করার উপর নির্ভর করত, তারা এখন একটি ত্রুটি পাবে।

SendRate

{ "value": 500, "bucket": "1s", "avoid": false }

সেন্ড থ্রটল করে। value হল প্রতি bucket-এ বার্তা; সাধারণ bucket হল "1s"।

SilentHours

{ "avoid": true }

মার্কেটিং মেসেজ ডিফল্টভাবে অ্যাপ্লিকেশনের সাইলেন্ট আওয়ার মেনে চলে: সাইলেন্ট আওয়ারের সময় চ্যানেলের সেটিংস অনুযায়ী সেগুলি তা শেষ না হওয়া পর্যন্ত আটকে রাখা হয় অথবা পাঠানো হয় না। সাইলেন্ট আওয়ারের সময়ও এই মেসেজ পাঠাতে avoid-কে true সেট করুন। যেসব মেসেজের message_type হল MESSAGE_TYPE_TRANSACTIONAL, সেগুলি কখনোই সাইলেন্ট আওয়ারে আটকে থাকে না, তাই তাদের এই ফিল্ডের প্রয়োজন নেই।

প্ল্যাটফর্ম enum

IOS, ANDROID, OSX, WINDOWS, AMAZON, SAFARI, CHROME, FIREFOX, IE, EMAIL, HUAWEI_ANDROID, SMS, WEB, KAKAO, TELEGRAM, LINE, WHATS_APP, VIBER, FB_MESSENGER।

RegistrationType enum

• REGISTRATION_TYPE_DEFAULT: Pushwoosh-এ রেজিস্টার করা হয়নি এমন আইডেন্টিফায়ারগুলি বাদ দেয়। ডিফল্ট।
• REGISTRATION_TYPE_NONE: তালিকাভুক্ত প্রতিটি hwid-এ পাঠায়, এর জন্য কোনো ডিভাইস সংরক্ষণ না করে।
• REGISTRATION_TYPE_FORCE: প্রতিটি অজানা hwid-কে টার্গেট করা চ্যানেলে একটি ডিভাইস হিসেবে রেজিস্টার করে, তারপর তাতে পাঠায়। ইমেল, SMS, WhatsApp, LINE, Viber, এবং Kakao-তে প্রযোজ্য।

MessageType enum

• MESSAGE_TYPE_UNSPECIFIED: MESSAGE_TYPE_MARKETING-এর সমতুল্য।
• MESSAGE_TYPE_MARKETING: কন্ট্রোল-গ্রুপ ফিল্টারিং, ফ্রিকোয়েন্সি ক্যাপিং এবং সাইলেন্ট আওয়ারের অধীন।
• MESSAGE_TYPE_TRANSACTIONAL: কন্ট্রোল-গ্রুপ ফিল্টারিং, ফ্রিকোয়েন্সি ক্যাপিং এবং সাইলেন্ট আওয়ার এড়িয়ে যায়। অর্ডার কনফার্মেশন, OTP, এবং অনুরূপ ক্রিটিক্যাল ফ্লো-এর জন্য ব্যবহার করুন।

সম্পর্কিত

নোটিফাই ব্যাচ

বাতিল করুন

পেলোড রেফারেন্স

ইমেল পেলোড রেফারেন্স

v1 থেকে মাইগ্রেশন