Notify

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

एक एकल संदेश बनाता है और शेड्यूल करता है।

अनुरोध संरचना

अनुरोध बॉडी एक NotifyRequest है जिसमें ठीक दो में से एक प्रकार होता है:

segment: सेगमेंट कोड द्वारा एक ऑडियंस सेगमेंट को लक्षित करें, या — पहले एक सेगमेंट बनाए बिना — एक seglang एक्सप्रेशन या एक संरचित फ़िल्टर एक्सप्रेशन।
transactional: hwids, यूज़र आईडी, पुश टोकन, या परीक्षण उपकरणों की एक स्पष्ट सूची में भेजें।

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

फ़ील्ड	प्रकार	विवरण
`transaction_id`	string	वैकल्पिक। अनुरोध के लिए इडेम्पोटेंसी कुंजी — `segment` और `transactional` दोनों के साथ काम करती है। 5 मिनट के भीतर समान `transaction_id` के साथ एक दोहराया गया कॉल डुप्लिकेट संदेश भेजने के बजाय मूल `message_code` लौटाता है। प्रति तार्किक भेजने के लिए एक UUID या किसी अन्य अद्वितीय मान का उपयोग करें।

डिडुप्लीकेशन केवल transaction_id पर मेल खाता है। यदि कोई पुन: प्रयास समान transaction_id का पुन: उपयोग करता है लेकिन एक अलग segment / transactional बॉडी भेजता है, तो मूल message_code अभी भी लौटाया जाता है और नई बॉडी को चुपचाप छोड़ दिया जाता है — इसकी तुलना पहले अनुरोध से नहीं की जाती है। तार्किक रूप से अलग-अलग संदेशों में कभी भी transaction_id का पुन: उपयोग न करें।

यह लीगेसी Messages API पर transactionId के समान डिडुप्लीकेशन तंत्र है, जो समान 5-मिनट की स्टोरेज विंडो साझा करता है, इसलिए एक पुन: प्रयास किए गए अनुरोध को /createMessage और Notify दोनों में डिडुप्लीकेट किया जाता है। यह PW_Conversion राजस्व घटनाओं पर transaction_id विशेषता से असंबंधित है, जिसे Pushwoosh जैसा है वैसा ही संग्रहीत करता है और डिडुप्लीकेशन के लिए उपयोग नहीं करता है।

NotifySegment

उन उपयोगकर्ताओं को लक्षित करता है जो एक ऑडियंस सेगमेंट या फ़िल्टर एक्सप्रेशन से मेल खाते हैं। code, expression, या filter_expression में से ठीक एक सेट करें। 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 / टेलीग्राम / काकाओ / लाइन / व्हाट्सएप / वाइबर / फेसबुक मैसेंजर पेलोड। `email_payload` के साथ परस्पर अनन्य।
`email_payload`	`EmailPayload`	ईमेल पेलोड।
`campaign`	string	इस संदेश को एट्रिब्यूट करने के लिए अभियान कोड।
`campaign_name`	string	इस संदेश का आंतरिक नाम, जो Message History में पंक्ति के शीर्षक के रूप में और उसके एक्सपोर्ट में दिखाया जाता है। ऊपर दिए `campaign` से इसका कोई संबंध नहीं है। यह संदेशों को समूहीकृत नहीं करता और डिलीवरी को प्रभावित नहीं करता। अधिकतम 255 वर्ण, ट्रिम किया गया। इसे छोड़ दें या खाली रहने दें, ताकि पंक्ति का शीर्षक पेलोड की अपनी सामग्री से बने।
`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` होता है, तो सेगमेंट द्वारा मेल खाने वाले प्रत्येक डिवाइस के बजाय प्रत्येक उपयोगकर्ता के सबसे हाल ही में सक्रिय डिवाइस (नवीनतम लास्ट एप्लिकेशन ओपन वाले) पर संदेश वितरित करता है। `platforms` तक सीमित: केवल उन प्लेटफ़ॉर्म पर डिवाइस पर विचार किया जाता है, और यदि किसी के पास लास्ट एप्लिकेशन ओपन डेटा नहीं है, तो भेजने को छोड़ने के बजाय पहले मेल खाने वाले डिवाइस का उपयोग किया जाता है। डिफ़ॉल्ट `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 लौटता है:

{
  "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 / टेलीग्राम / काकाओ / लाइन / व्हाट्सएप / वाइबर / फेसबुक मैसेंजर पेलोड।
`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` के माध्यम से पंजीकृत पहचानकर्ता सूचीबद्ध नहीं होते।

/getMessageDetails 10 से कम उपयोगकर्ताओं और 10 से कम डिवाइस को तुरंत भेजा गया transactional संदेश नहीं ढूँढ सकता, क्योंकि ऐसा संदेश संग्रहीत नहीं होता। 10 से कम प्राप्तकर्ताओं को तुरंत भेजे गए संदेश देखें।

कोई प्राप्तकर्ता नहीं मिला

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: 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`	`best_time_to_send` किसी `transactional` भेजने पर सेट है।
`BestTimeToSendWithSendNow`	`at` / `after` “अभी” में बदलता है (अतीत का `at` या शून्य `after`)।

GeoZone

geo_zone के लिए एक बार का वृत्त, जो अनुरोध में ही परिभाषित होता है। यह सहेजा गया जियोज़ोन नहीं है: जियो अभियान और जियोज़ोन एपीआई शामिल नहीं होते, और एप्लिकेशन में कुछ भी संग्रहीत नहीं होता।

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

फ़ील्ड	प्रकार	विवरण
`lat`	double	वृत्त के केंद्र का अक्षांश, डिग्री में। आवश्यक।
`lng`	double	वृत्त के केंद्र का देशांतर, डिग्री में। आवश्यक।
`range`	double	मीटर में वृत्त की त्रिज्या। आवश्यक।

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): उन उपयोगकर्ताओं से सॉफ्ट-अवॉइड करें जो पहले ही कैप तक पहुंच चुके हैं (वे अभी भी एनालिटिक्स में गिने जाते हैं)।

SendRate

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

भेजने को थ्रॉटल करता है। value प्रति bucket संदेश है; सामान्य bucket "1s" है।

SilentHours

{ "avoid": true }

मार्केटिंग संदेश डिफ़ॉल्ट रूप से एप्लिकेशन के साइलेंट आवर्स का पालन करते हैं: साइलेंस पीरियड के दौरान, चैनल की सेटिंग्स के आधार पर, उन्हें इसके समाप्त होने तक रोका जाता है या भेजा ही नहीं जाता। साइलेंस पीरियड के दौरान भी यह संदेश भेजने के लिए avoid को true पर सेट करें। message_type MESSAGE_TYPE_TRANSACTIONAL वाले संदेश साइलेंट आवर्स से कभी नहीं रोके जाते, इसलिए उन्हें इस फ़ील्ड की आवश्यकता नहीं है।

प्लेटफ़ॉर्म एनम

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

RegistrationType एनम

REGISTRATION_TYPE_DEFAULT: उन पहचानकर्ताओं को छोड़ देता है जो Pushwoosh में पंजीकृत नहीं हैं। डिफ़ॉल्ट।
REGISTRATION_TYPE_NONE: सूचीबद्ध प्रत्येक hwid पर उसके लिए डिवाइस सहेजे बिना भेजता है।
REGISTRATION_TYPE_FORCE: प्रत्येक अज्ञात hwid को लक्षित चैनल पर डिवाइस के रूप में पंजीकृत करता है, फिर उस पर भेजता है। ईमेल, SMS, WhatsApp, LINE, Viber और Kakao पर लागू होता है।

MessageType एनम

MESSAGE_TYPE_UNSPECIFIED: MESSAGE_TYPE_MARKETING के बराबर।
MESSAGE_TYPE_MARKETING: कंट्रोल-ग्रुप फ़िल्टरिंग, फ़्रीक्वेंसी कैपिंग और साइलेंट आवर्स के अधीन।
MESSAGE_TYPE_TRANSACTIONAL: कंट्रोल-ग्रुप फ़िल्टरिंग, फ़्रीक्वेंसी कैपिंग और साइलेंट आवर्स को छोड़ देता है। ऑर्डर पुष्टिकरण, OTPs, और इसी तरह के महत्वपूर्ण प्रवाहों के लिए उपयोग करें।