Automations API अवलोकन

Beta. Automations API बीटा में है और हम सक्रिय रूप से फीडबैक एकत्र कर रहे हैं। एंडपॉइंट, पेलोड और सीमाएँ हमारे विकसित होने के साथ बदल सकती हैं। कृपया सपोर्ट को फीडबैक और बग रिपोर्ट भेजें ताकि हम सही सुधारों को प्राथमिकता दे सकें।

Automations एंडपॉइंट आपको ऐसे नियम परिभाषित करने देते हैं जो आने वाले Instagram एंगेजमेंट और Facebook Page DM पर स्वचालित रूप से प्रतिक्रिया करते हैं। प्रत्येक ऑटोमेशन एक या अधिक triggers (वह घटना जो नियम को फ़ायर करती है) को एक या अधिक actions (जब यह फ़ायर होता है तो क्या होता है) से जोड़ता है। एक नियम कई ट्रिगर्स सुन सकता है और कई क्रियाएँ भेज सकता है — उसी एंगेजमेंट से आपकी एनालिटिक्स पाइपलाइन में एक वेबहुक फ़ायर करें और साथ ही एक DM भी भेजें। इंजन केवल उस एंगेजमेंट पर प्रतिक्रिया करता है जो कोई उपयोगकर्ता आपकी ओर निर्देशित करता है (एक टिप्पणी, स्टोरी उत्तर, DM, या प्रतिक्रिया) — यह कभी भी फ़ॉलो-ट्रिगर्ड DM, अजनबियों को पहला-संदेश DM, या बल्क आउटबाउंड नहीं भेजता — और Ayrshare की प्रति-खाता दर सीमाएँ, प्रति-प्राप्तकर्ता डुप्लीकेशन हटाना और आइडेम्पोटेंट वेबहुक इनजेशन विरासत में मिलती हैं।

sent का अर्थ है कि Meta ने संदेश स्वीकार किया, यह नहीं कि प्राप्तकर्ता को यह मिला। Instagram पर, डिलीवरी अंततः प्राप्तकर्ता की Message requests सेटिंग द्वारा तय होती है: यदि वे सभी से मैसेज रिक्वेस्ट की अनुमति नहीं देते हैं, तो Meta सफलता प्रतिक्रिया लौटाता है और संदेश को चुपचाप छोड़ देता है, और यह हर API परत पर अदृश्य है। यहाँ तक कि एक डिलीवर्ड टिप्पणी-ट्रिगर्ड DM भी एक मैसेज रिक्वेस्ट के रूप में पहुँचता है जिसे प्राप्तकर्ता को स्वीकार करना होगा (जब तक कि दोनों खातों के बीच पहले से कोई बातचीत मौजूद न हो)। पूर्ण विवरण के लिए देखें Automation DM Sent but Not Delivered।

यह कैसे काम करता है

एक ऑटोमेशन बनाएँ

POST /automations उन ट्रिगर्स और क्रियाओं के साथ जो आप चाहते हैं। ऑटोमेशन तुरंत सक्रिय हो जाता है।

एक अंतिम उपयोगकर्ता एंगेज करता है

कोई आपकी पोस्ट पर टिप्पणी करता है, आपकी स्टोरी का जवाब देता है, DM भेजता है, या DM पर प्रतिक्रिया देता है। Meta वेबहुक को Ayrshare को डिलीवर करता है।

Ayrshare मिलाता है और भेजता है

Instagram के एंटी-स्पैम हेयुरिस्टिक्स के भीतर रहने के लिए एंगेजमेंट पर 20–60 सेकंड का जिटर लागू किया जाता है। इसके बाद इंजन घटना से मेल खाने वाले प्रत्येक नियम को खोजता है, प्रति-क्रिया डुप्लीकेशन हटाने और आपकी दैनिक DM सीमा की जाँच करता है, फिर प्रत्येक क्रिया चलाता है।

निरीक्षण करें कि क्या फ़ायर हुआ

GET /automations/:id/activity ऑडिट लॉग लौटाता है — प्रत्येक डिस्पैच प्रयास, प्रति-क्रिया परिणाम और कोई भी त्रुटियाँ।

Triggers

आप एक ऑटोमेशन में 50 ट्रिगर्स तक जोड़ सकते हैं। प्रत्येक ट्रिगर type फ़ील्ड पर एक विवेकाधीन यूनियन है; टाइप-विशिष्ट फ़ील्ड्स एक ही स्तर पर होते हैं। प्लेटफ़ॉर्म कॉलम दिखाता है कि प्रत्येक ट्रिगर कहाँ उपलब्ध है; Facebook के लिए क्या आवश्यक है, यह जानने के लिए Facebook Pages देखें।

Type	कब फ़ायर होता है	प्लेटफ़ॉर्म	कॉन्फ़िग
`comment_keyword`	किसी पोस्ट या रील पर कीवर्ड से मेल खाने वाली टिप्पणी आती है	`instagram`	`postId` (आवश्यक — एक पोस्ट ID, या `"all"`); `keywords` (आवश्यक, ≥1 प्रविष्टि)
`story_reply`	उपयोगकर्ता DM के माध्यम से किसी स्टोरी का जवाब देता है	`instagram`	`storyId` (वैकल्पिक — एक स्टोरी ID, या `"all"`)
`dm_reaction`	उपयोगकर्ता आपके किसी DM पर इमोजी के साथ प्रतिक्रिया देता है	`instagram`, `facebook`	`emoji` (वैकल्पिक — किसी भी इमोजी पर फ़ायर करने के लिए छोड़ दें)
`dm_keyword`	उपयोगकर्ता एक DM भेजता है जिसका टेक्स्ट कीवर्ड से मेल खाता है	`instagram`, `facebook`	`keywords` (आवश्यक, ≥1 प्रविष्टि)

कीवर्ड मिलान case-insensitive और पूर्ण-शब्द है। यदि किसी घटना में कॉन्फ़िगर किए गए कीवर्ड में से कोई एक शामिल है तो यह एक कीवर्ड-फ़िल्टर्ड ट्रिगर को संतुष्ट करता है।

`"all"` के साथ एवरग्रीन नियम

किसी एक विशिष्ट कंटेंट के बजाय कनेक्टेड खाते की हर पोस्ट, रील या स्टोरी पर फ़ायर करने के लिए postId (या storyId) को शाब्दिक lowercase स्ट्रिंग "all" पर सेट करें। ऐसे नियम के लिए यही चाहिए जो नया कंटेंट प्रकाशित होने पर भी काम करता रहे, बिना प्रति पोस्ट किसी API कॉल के:

{
  "type": "comment_keyword",
  "postId": "all",
  "keywords": ["LINK", "INFO"]
}

वैल्यू ठीक "all" होनी चाहिए। "ALL" या " all" जैसे वेरिएंट को ऐसी पोस्ट ID के रूप में सहेजे जाने के बजाय — जो कभी मेल नहीं खाती — एक सत्यापन त्रुटि के साथ अस्वीकार कर दिया जाता है। "all" कभी भी कनेक्टेड खाते से आगे नहीं फैलता — एक प्रोफ़ाइल पर बना नियम दूसरी प्रोफ़ाइल के कंटेंट पर फ़ायर नहीं कर सकता। आपकी दैनिक DM कैप और एंगेजमेंट-एंकर्ड भेजने के नियम ठीक वैसे ही लागू होते हैं जैसे वे एकल-पोस्ट नियम पर लागू होते हैं।

डुप्लीकेशन हटाना प्रति ऑटोमेशन और प्राप्तकर्ता गिना जाता है, प्रति पोस्ट नहीं। एक "all" नियम पर, जो उपयोगकर्ता डेडअप विंडो (डिफ़ॉल्ट रूप से 7 दिन) के भीतर दो अलग-अलग पोस्ट पर कीवर्ड की टिप्पणी करता है, उसे DM केवल एक बार मिलता है; दूसरी गतिविधि deduplicated के रूप में दर्ज की जाती है। एक छोटा dedupWindowMinutes केवल उस विंडो को छोटा करता है; यह डुप्लीकेशन हटाने को प्रति पोस्ट नहीं बनाता। इसे 0 पर सेट करने से डुप्लीकेशन हटाना बंद हो जाता है, इसलिए हर मेल खाने वाली टिप्पणी एक DM भेजती है, एक ही पोस्ट पर दोहराई गई टिप्पणियों सहित।

स्टोरी ट्रिगर्स पर, storyId छोड़ना "all" जैसा ही व्यवहार करता है। "all" को प्राथमिकता दें — यह इरादे को स्पष्ट रूप से बताता है, और छोड़ने की सुविधा भविष्य की रिलीज़ में रिटायर कर दी जाएगी, जिसकी अग्रिम सूचना Upcoming API Changes पर दी जाएगी।

Facebook Pages

प्रोफ़ाइल से लिंक किए गए Facebook Page पर ऑटोमेशन चलाने के लिए platform को facebook पर सेट करें। DM, Page से Messenger के ज़रिए भेजे जाते हैं।

ट्रिगर्स: dm_keyword और dm_reaction। टिप्पणी और स्टोरी ट्रिगर्स फ़िलहाल केवल Instagram के लिए हैं, और इनमें से किसी का उपयोग करने वाला Facebook ऑटोमेशन सत्यापन त्रुटि के साथ अस्वीकार कर दिया जाता है।
Messaging: प्रोफ़ाइल के लिए Facebook पर Messaging सक्रिय होना आवश्यक है, ठीक वैसे ही जैसे Messages API से Facebook DM भेजने के लिए।
प्राप्तकर्ता: {{recipient_id}} उपयोगकर्ता की Page-स्कोप्ड ID (PSID) है। {{recipient_username}} खाली रहता है, क्योंकि Messenger वेबहुक में यूज़रनेम शामिल नहीं होता।

{
  "platform": "facebook",
  "name": "Price list on request",
  "triggers": [{ "type": "dm_keyword", "keywords": ["price"] }],
  "actions": [{ "type": "send_dm", "message": "Here is our price list: https://example.com/prices" }]
}

Actions

आप एक ऑटोमेशन में 50 क्रियाएँ तक जोड़ सकते हैं। वे क्रमिक रूप से चलती हैं; प्रत्येक परिणाम गतिविधि रो पर दर्ज किया जाता है।

Type	प्रभाव	कॉन्फ़िग
`send_dm`	नियम को ट्रिगर करने वाले उपयोगकर्ता को DM भेजता है (Instagram पर, या आपके Facebook Page से Messenger के ज़रिए), एक टेम्प्लेट किए गए संदेश या प्रति फ़ायर आपके द्वारा जनरेट किए गए टेक्स्ट का उपयोग करके।	`message` (आवश्यक, टेम्प्लेट किया गया); `messageUrl` (वैकल्पिक); `timeoutMs` (वैकल्पिक)
`fire_webhook`	आपके खाता-स्तर वेबहुक URL पर ऑटोमेशन संदर्भ को POST करता है (`POST /hook/webhook` के माध्यम से कॉन्फ़िगर करें)।	`sendCompletedEvent` (वैकल्पिक, boolean — `automation.completed` भी भेजता है)। पेलोड शेप निश्चित है; नीचे देखें
`send_email`	प्लेटफ़ॉर्म की मेल पाइपलाइन के माध्यम से एक ईमेल कतारबद्ध करता है।	`to` (आवश्यक, ईमेल); `subject` (वैकल्पिक, टेम्प्लेट किया गया); `message` (आवश्यक, टेम्प्लेट किया गया)

प्रति-क्रिया डेडअप विंडो

प्रत्येक क्रिया — प्रकार की परवाह किए बिना — अतिरिक्त रूप से एक वैकल्पिक शीर्ष-स्तरीय dedupWindowMinutes फ़ील्ड स्वीकार करती है जो केवल उस क्रिया के लिए डिफ़ॉल्ट 7-दिन प्रति-प्राप्तकर्ता डेडअप विंडो को ओवरराइड करती है।

उस क्रिया के लिए डेडअप को पूरी तरह से अक्षम करने के लिए 0 सेट करें (आमतौर पर fire_webhook / send_email के लिए जहाँ प्राप्तकर्ता प्रत्येक घटना की अपेक्षा करता है)।
525600 (एक वर्ष) पर सीमित।

Action with a 24h dedup override

{
  "type": "send_dm",
  "message": "Thanks {{recipient_username}}!",
  "dedupWindowMinutes": 1440
}

डायनामिक संदेश सामग्री

डिफ़ॉल्ट रूप से, send_dm नियम को ट्रिगर करने वाले हर व्यक्ति को एक ही message भेजता है। {{recipient_username}} जैसे प्लेसहोल्डर्स ही एकमात्र हिस्सा हैं जो हर व्यक्ति के लिए बदलते हैं। क्रिया पर messageUrl सेट करें और इसके बजाय आपका अपना सर्वर हर व्यक्ति के लिए DM लिखता है: हर बार जब नियम मेल खाता है, हम आपके एंडपॉइंट से पूछते हैं कि क्या कहना है, फिर उसके उत्तर को DM के रूप में भेजते हैं। उदाहरण। आपका नियम किसी पोस्ट पर “LINK” टिप्पणी करने वाले हर व्यक्ति को उत्तर देता है, और messageUrl आपके सर्वर की ओर इशारा करता है। जब Ava “LINK please!” टिप्पणी करती है:

हम विवरण आपके messageUrl पर POST करते हैं: किसने टिप्पणी की ("recipientUsername": "ava"), उन्होंने क्या लिखा, और यह किस पोस्ट पर था।
आपका सर्वर Ava के लिए एक उत्तर लिखता है, उदाहरण के लिए सिर्फ़ उसके लिए बनाए गए ट्रैकिंग लिंक के साथ, और { "message": "Hi ava, here's your link: https://example.com/r/12345" } उत्तर देता है।
हम वह टेक्स्ट Ava को DM के रूप में भेजते हैं, ठीक वैसे ही जैसे आपने लिखा था।

यदि आपका सर्वर timeoutMs के भीतर उत्तर नहीं देता, कोई त्रुटि लौटाता है, या कुछ ऐसा लौटाता है जिसका हम उपयोग नहीं कर सकते, तो हम इसके बजाय Ava को क्रिया का सामान्य message भेजते हैं, ताकि उसे फिर भी उत्तर मिले। इसे किसी send_dm क्रिया में इस तरह जोड़ें:

send_dm with messageUrl

{
  "type": "send_dm",
  "messageUrl": "https://yourapp.example.com/automations/message",
  "timeoutMs": 3000,
  "message": "Thanks for commenting! Here is the link: https://example.com"
}

messageUrl वह जगह है जहाँ हम टेक्स्ट माँगते हैं। message अब भी आवश्यक है और यही फ़ॉलबैक है: इसे कभी भी आपके सर्वर पर नहीं भेजा जाता, और जब भी आपका सर्वर समय पर उत्तर नहीं देता, कोई त्रुटि लौटाता है, या कुछ ऐसा लौटाता है जिसका हम उपयोग नहीं कर सकते (नीचे दी गई चेतावनी देखें), तो हम इसके बजाय इसे DM करते हैं। timeoutMs वैकल्पिक है (डिफ़ॉल्ट 3000, अधिकतम 5000)। हम आपके एंडपॉइंट को क्या भेजते हैं। इस JSON बॉडी के साथ एक POST:

Callback request body

{
  "automationId":      "auto_9xKp2Lm4nQ",
  "triggerId":         "trg_a1b2c3",
  "trigger":           "comment_keyword",
  "platform":          "instagram",
  "recipientId":       "17841401234567890",
  "recipientUsername": "ava",
  "keyword":           "LINK",
  "activityId":        "auto_9xKp2Lm4nQ:trg_a1b2c3:comment.received:17912345678901234",
  "actionId":          "act_dm_1",
  "eventId":           "comment.received:17912345678901234",
  "commentId":         "17912345678901234",
  "commentText":       "LINK please!",
  "postId":            "17998765432109876",
  "storyId":           null,
  "timestamp":         "2026-05-12T09:14:22.000Z",
  "timeStamp":         1778577262
}

फ़ील्ड	अर्थ
`automationId`, `triggerId`, `trigger`, `platform`	कौन-सा ऑटोमेशन और ट्रिगर फ़ायर हुआ, जैसा `fire_webhook` पेलोड पर होता है
`recipientId`, `recipientUsername`	वह व्यक्ति जिसे DM जाता है। जब ट्रिगर में यह शामिल नहीं होता (उदाहरण के लिए `dm_keyword`), तो `recipientUsername` `null` होता है
`keyword`	वह कीवर्ड जो मेल खाया, या `null`
`activityId`	इस फ़ायर की गतिविधि प्रविष्टि, ताकि आप इसे `GET /automations/:id/activity` से मिला सकें
`actionId`	कौन-सी `send_dm` क्रिया पूछ रही है, `actionResults[].actionId` से मेल खाती हुई। इससे एक एंडपॉइंट एक ही ऑटोमेशन पर कई `send_dm` क्रियाओं को सेवा दे सकता है
`eventId`	उस एंगेजमेंट के लिए हमारी id जिसके कारण फ़ायर हुआ
`commentId`	टिप्पणी ट्रिगर्स के लिए Instagram टिप्पणी id; DM और स्टोरी ट्रिगर्स के लिए `null`
`commentText`	वह टेक्स्ट जो मेल खाया: टिप्पणी, DM, या प्रतिक्रिया इमोजी। जब कोई न हो (उदाहरण के लिए `story_reply`), तो `null`
`postId`, `storyId`	वह पोस्ट या स्टोरी जिस पर एंगेजमेंट हुआ, या `null`
`timestamp`	हमने अनुरोध कब किया, ISO 8601
`timeStamp`	वही क्षण Unix समय के रूप में सेकंड में। केवल तब मौजूद होता है जब कॉलबैक साइन किया गया हो, जैसा हमारे वेबहुक्स पर होता है

यदि आपने एक वेबहुक सीक्रेट रजिस्टर किया है, तो बॉडी को उसी सीक्रेट से साइन किया जाता है जिससे आपके automations वेबहुक्स, और उसी तरीके से: X-Authorization-Content-SHA256 रॉ बॉडी का HMAC-SHA256 है, और X-Authorization-Timestamp बॉडी का timeStamp ले जाता है। हमारे वेबहुक्स के लिए आप जो सत्यापन कोड पहले से उपयोग करते हैं, वह बिना बदलाव के काम करता है। यदि कोई सीक्रेट रजिस्टर है लेकिन हम उस क्षण उसे पढ़ नहीं सकते, तो हम कॉलबैक को बिना साइन किए नहीं भेजते; इसके बजाय हम आपका message टेम्प्लेट भेजते हैं। यह कहाँ इशारा कर सकता है। messageUrl एक सार्वजनिक HTTPS पता होना चाहिए। ऐसा URL जो किसी private, loopback, link-local या cloud-metadata पते पर रिज़ॉल्व होता है, अस्वीकार कर दिया जाता है, और रीडायरेक्ट्स का पालन नहीं किया जाता — एक 3xx उत्तर विफलता माना जाता है। दोनों ही स्थितियों में इसके बजाय टेम्प्लेट भेजा जाता है। आपका एंडपॉइंट क्या लौटाता है। अधिकतम 16 KB की JSON बॉडी के साथ 200 लौटाएँ, जिसमें 1 से 1000 वर्णों की एक message स्ट्रिंग हो:

{ "message": "Hi ava — grabbed that link for you: https://example.com/r/12345" }

आपका टेक्स्ट अक्षरशः भेजा जाता है। इस पर {{placeholder}} प्रतिस्थापन लागू नहीं होता, इसलिए आपके जनरेट किए गए टेक्स्ट में शाब्दिक {{ प्राप्तकर्ता तक वैसे ही पहुँचता है जैसा लिखा गया है।

message आवश्यक रहता है, और यह सजावट नहीं है। यदि आपका एंडपॉइंट टाइम आउट हो जाता है, non-2xx लौटाता है, ऐसी बॉडी लौटाता है जिसका हम उपयोग नहीं कर सकते, या बार-बार की विफलताओं के बाद अस्थायी रूप से circuit-broken कर दिया गया है, तो हम इसके बजाय रेंडर किया गया message टेम्प्लेट भेजते हैं। वह भेजना फिर भी विफल हो सकता है, उदाहरण के लिए यदि टेम्प्लेट खाली रेंडर होता है (नीचे देखें) या Instagram उसे अस्वीकार कर देता है। हम कभी भी कॉलबैक का पुनः प्रयास नहीं करते — पुनः प्रयास से प्राप्तकर्ता को दो संदेश भेजे जाने का जोखिम होता है।

timeoutMs का डिफ़ॉल्ट 3000 है। अधिकतम 5000 है: ऑटोमेशन बनाते या अपडेट करते समय बड़ी वैल्यू को सत्यापन त्रुटि के साथ अस्वीकार कर दिया जाता है। यह पूरे आदान-प्रदान को कवर करता है, जिसमें आपकी प्रतिक्रिया बॉडी पढ़ना भी शामिल है। इसके लिए समय का ध्यान रखें: DM आपके एंडपॉइंट के उत्तर देने के बाद भेजा जाता है, इसलिए धीमा एंडपॉइंट संदेश में देरी करता है। GET /automations/:id/activity पर जाँचें कि किसी फ़ायर ने कौन-सा रास्ता लिया। actionResults[] में एक send_dm प्रविष्टि DM टेक्स्ट तय हो जाने के बाद messageSource ले जाती है, तब भी जब भेजना बाद में विफल हो गया। यह तब अनुपस्थित होता है जब क्रिया उससे पहले रुक गई, उदाहरण के लिए आपके अपने खाते को skipped DM या एक deduplicated क्रिया:

`messageSource`	अर्थ
`template`	कोई `messageUrl` कॉन्फ़िगर नहीं है; स्थिर `message` का उपयोग किया गया
`callback`	आपके एंडपॉइंट ने उत्तर दिया और उसके टेक्स्ट का उपयोग किया गया
`fallback`	`messageUrl` सेट था लेकिन उपयोग योग्य नहीं था; इसके बजाय `message` का उपयोग किया गया

messageSource बताता है कि DM किस टेक्स्ट से बनाया गया था, यह नहीं कि वह डिलीवर हुआ या नहीं। उसके लिए प्रविष्टि का status पढ़ें। अकेले फ़ॉलबैक से क्रिया विफल नहीं होती: जब टेम्प्लेट DM डिलीवर हो जाता है, तो प्रविष्टि sent होती है, और कॉलबैक का उपयोग न किए जाने का कारण errorDetails पर होता है। यदि टेम्प्लेट DM भी विफल हो जाता है, तो प्रविष्टि failed होती है और errorDetails भेजने की त्रुटि और उसके बाद कॉलबैक का कारण देता है। इस पर नज़र रखें: अन्यथा हर फ़ायर पर विफल होने वाला कॉलबैक बिल्कुल वैसा ही दिखता है जैसा ठीक से काम करने वाला। अपने message को अपने आप में भेजने योग्य रखें। यदि यह किसी प्राप्तकर्ता के लिए खाली रेंडर होता है, उदाहरण के लिए ऐसे DM ट्रिगर पर अकेला {{recipient_username}} जिसमें कोई यूज़रनेम नहीं होता, और आपके कॉलबैक टेक्स्ट का उपयोग नहीं किया जाता, तो कोई DM नहीं भेजा जाता और क्रिया failed होती है, जिसका कारण errorDetails पर होता है।

वेबहुक घटनाएँ

दो घटनाएँ उस automations वेबहुक क्रिया पर डिलीवर की जाती हैं जिसे आप POST /hook/webhook के साथ रजिस्टर करते हैं। दोनों एक type फ़ील्ड ले जाती हैं — कुछ भी और पढ़ने से पहले उस पर स्विच करें।

`type`	कब भेजी जाती है
`automation.triggered`	नियम की `fire_webhook` क्रिया चलती है
`automation.completed`	डिस्पैच अपने परिणाम के साथ समाप्त हुआ

automation.completed डिफ़ॉल्ट रूप से बंद है। किसी ऑटोमेशन के लिए इसे उसकी fire_webhook क्रिया पर "sendCompletedEvent": true सेट करके चालू करें। अन्यथा यह बंद रहती है, इसलिए प्रति फ़ायर एक पेलोड के लिए बनाया गया रिसीवर बिल्कुल एक ही प्राप्त करता रहता है। automation.triggered हर मिलान का रिकॉर्ड नहीं है: यह केवल तभी भेजी जाती है जब fire_webhook स्वयं चलता है, इसलिए ऐसा मिलान जो rate_limited या deduplicated में समाप्त होता है, केवल automation.completed उत्पन्न करता है। ऐसे ऑटोमेशन के लिए कोई भी घटना नहीं भेजी जाती जो डिस्पैच चलने से पहले निष्क्रिय हो गया या हटा दिया गया था।

`automation.triggered`

{
  "type":              "automation.triggered",
  "automationId":      "auto_9xKp2Lm4nQ",
  "triggerId":         "trg_a1b2c3",
  "trigger":           "comment_keyword",
  "platform":          "instagram",
  "recipientId":       "17841401234567890",
  "recipientUsername": "jane_doe",
  "keyword":           "LINK",
  "activityId":        "auto_9xKp2Lm4nQ:trg_a1b2c3:comment.received:17912345678901234",
  "actionId":          "act_wh_1",
  "eventId":           "comment.received:17912345678901234",
  "commentId":         "17912345678901234",
  "commentText":       "LINK please",
  "postId":            "17895695668004550",
  "storyId":           null,
  "timestamp":         "2026-05-12T09:14:22.000Z"
}

activityId वही रो है जो GET /automations/:id/activity लौटाता है, ताकि आप recipientId + triggerId + keyword पर मिलान करने के बजाय — जो तब अस्पष्ट होता है जब कई लोग एक ही कीवर्ड की टिप्पणी एक साथ करते हैं — दोनों को सटीक रूप से जोड़ सकें। actionId वह fire_webhook क्रिया है जिसने घटना भेजी, और actionResults[].actionId से मेल खाती है; यह एक ही नियम पर दो fire_webhook क्रियाओं को अलग-अलग पहचानने देती है। जिन फ़ील्ड्स को कोई ट्रिगर पॉप्युलेट नहीं करता वे छोड़ी जाने के बजाय null होती हैं, इसलिए शेप स्थिर है। recipientUsername dm_keyword, dm_reaction और story_reply के लिए null है, क्योंकि Meta के पेलोड में यह शामिल नहीं होता। commentId केवल comment_keyword और story_comment के लिए सेट होता है, postId केवल comment_keyword के लिए, और storyId केवल स्टोरी ट्रिगर्स के लिए। story_reply में कोई keyword नहीं होता। dm_keyword के लिए, commentText DM टेक्स्ट है; dm_reaction के लिए, commentText और keyword दोनों प्रतिक्रिया इमोजी हैं।

`automation.completed`

केवल तब भेजी जाती है जब ऑटोमेशन अपनी fire_webhook क्रिया पर ऑप्ट-इन करता है:

fire_webhook action with the outcome event on

{
  "type": "fire_webhook",
  "sendCompletedEvent": true
}

{
  "type":         "automation.completed",
  "automationId": "auto_9xKp2Lm4nQ",
  "triggerId":    "trg_a1b2c3",
  "trigger":      "comment_keyword",
  "platform":     "instagram",
  "recipientId":  "17841401234567890",
  "activityId":   "auto_9xKp2Lm4nQ:trg_a1b2c3:comment.received:17912345678901234",
  "eventId":      "comment.received:17912345678901234",
  "status":       "sent",
  "actionResults": [
    { "actionId": "act_dm_1", "type": "send_dm",      "status": "sent", "errorDetails": null, "messageSource": "callback" },
    { "actionId": "act_wh_1", "type": "fire_webhook", "status": "sent", "errorDetails": null }
  ],
  "errorDetails": null,
  "timestamp":    "2026-05-12T09:14:58.000Z"
}

status और प्रत्येक actionResults[].status गतिविधि लॉग जैसी ही वैल्यूज़ का उपयोग करते हैं — sent, failed, rate_limited, deduplicated, skipped, auth_error — इसलिए सामान्य स्थिति में आप बिना पोलिंग किए जान जाते हैं कि डिस्पैच कैसे समाप्त हुआ। हालाँकि इस घटना की डिलीवरी best-effort है: यदि परिणाम रिकॉर्ड करने और घटना को कतारबद्ध करने के बीच प्रक्रिया रुक जाती है, तो यह नहीं भेजी जाती। गतिविधि लॉग सत्य का रिकॉर्ड है, इसलिए यदि आपको हर परिणाम चाहिए, तो किसी भी ऐसे activityId के लिए GET /automations/:id/activity के विरुद्ध मिलान करें जिसने परिणाम रिपोर्ट नहीं किया है। एक send_dm परिणाम में messageSource भी होता है, जैसा गतिविधि लॉग पर होता है: template, callback या fallback, ताकि आप बिना पोलिंग किए उस messageUrl को पहचान सकें जो बार-बार फ़ॉलबैक पर जा रहा है। परिणामों को अपनी कॉन्फ़िगर की गई क्रियाओं से स्थिति के बजाय actionId द्वारा मिलाएँ — एक ही प्रकार की दो क्रियाएँ केवल इसी तरह अलग पहचानी जा सकती हैं। actionResults तीन मामलों में खाली होता है, प्रत्येक में कारण (जहाँ कोई है) शीर्ष-स्तरीय errorDetails पर होता है: rate_limited (आपकी दैनिक कैप पूरी हो गई), deduplicated (हर क्रिया अपनी डेडअप विंडो के भीतर थी), और failed जब डिस्पैच का अधिकतम बार पुनः प्रयास किया गया और वह पूरा नहीं हुआ। उस अंतिम मामले में कुछ क्रियाएँ पहले ही चल चुकी हो सकती हैं, इसलिए हो सकता है कि DM भेजा जा चुका हो और automation.triggered पहले ही भेजी जा चुकी हो। वेबहुक डिलीवरी at-least-once है, इसलिए एक ही घटना कभी-कभी दो बार पहुँच सकती है, और जिस डिस्पैच का पुनः प्रयास किया जाता है वह automation.triggered को नए hookId के साथ फिर से भेज सकता है। कभी भी hookId पर डुप्लीकेशन न हटाएँ। प्रत्येक घटना प्रकार को अलग-अलग कुंजीबद्ध करें, ताकि एक को प्रोसेस करना दूसरे को कभी न दबाए: automation.completed को activityId पर (प्रत्येक गतिविधि का एक परिणाम होता है), और automation.triggered को activityId प्लस actionId पर (प्रति fire_webhook क्रिया एक)। दोनों घटनाएँ स्वतंत्र रूप से डिलीवर की जाती हैं, इसलिए automation.completed कभी-कभी automation.triggered से पहले पहुँच सकती है।

यदि कोई वेबहुक रजिस्टर नहीं है

fire_webhook प्रोफ़ाइल पर रजिस्टर की गई automations क्रिया पर POST करता है, और आपके Primary Profile पर फ़ॉलबैक करता है। messages जैसी किसी अन्य क्रिया पर कोई फ़ॉलबैक नहीं है। यदि दोनों में से कोई भी रजिस्ट्रेशन मौजूद नहीं है, तो automation.triggered चुपचाप नहीं छोड़ी जाती: क्रिया को गतिविधि रो पर failed के रूप में दर्ज किया जाता है, जिसमें कारण actionResults[].errorDetails में होता है। (automation.completed के पास भी जाने के लिए कोई जगह नहीं होती, और इसे रिकॉर्ड नहीं किया जाता।) डिस्पैच की समग्र स्थिति फिर सामान्य वरीयता का पालन करती है: auth_error यदि किसी क्रिया को प्रमाणीकरण त्रुटि मिली, अन्यथा sent यदि कोई क्रिया स्वीकार की गई, अन्यथा failed। इसलिए गुम वेबहुक ऑटोमेशन के विफलता आँकड़ों में केवल तभी गिना जाता है जब नियम पर किसी और चीज़ ने नहीं भेजा; जब किसी अन्य क्रिया ने भेजा (और किसी को प्रमाणीकरण त्रुटि नहीं मिली), तो डिस्पैच sent में समाप्त होता है और विफल वेबहुक केवल actionResults[] में दिखता है। fire_webhook के sent परिणाम का अर्थ है कि घटना आपके URL पर डिलीवरी के लिए कतारबद्ध की गई, यह नहीं कि आपके एंडपॉइंट ने इसे स्वीकार किया। डिलीवरी का फिर अपने शेड्यूल पर पुनः प्रयास किया जाता है।

टेम्प्लेट वेरिएबल्स

send_dm.message, send_email.subject, और send_email.message {{placeholder}} प्रतिस्थापन का समर्थन करते हैं। अज्ञात प्लेसहोल्डर्स को क्रिएट/अपडेट समय पर अस्वीकार कर दिया जाता है (एक 473 सत्यापन त्रुटि के रूप में) ताकि टाइपो कभी भी अक्षरशः {{foo}} को ग्राहक-सामने वाले संदेश में चुपचाप लीक न करे।

Placeholder	किस पर हल होता है
`{{recipient_username}}`	एंगेज करने वाले उपयोगकर्ता का Instagram हैंडल, कमेंट ट्रिगर्स पर। DM और स्टोरी-रिप्लाई ट्रिगर्स पर, और Facebook पर हमेशा, खाली रहता है
`{{recipient_id}}`	एंगेज करने वाले उपयोगकर्ता की ID: Instagram पर Instagram-स्कोप्ड ID (IGSID), Facebook पर Page-स्कोप्ड ID (PSID)
`{{recipient_name}}`	आरक्षित; भविष्य के संवर्धन स्रोत द्वारा पॉप्युलेट होने तक खाली में हल होता है
`{{sender_username}}`	आरक्षित; फ़िलहाल हर प्लेटफ़ॉर्म पर खाली में हल होता है
`{{sender_name}}`	आरक्षित; फ़िलहाल हर प्लेटफ़ॉर्म पर खाली में हल होता है
`{{comment_text}}`	ट्रिगर को फ़ायर करने वाली टिप्पणी / DM / स्टोरी उत्तर का टेक्स्ट
`{{comment_id}}`	फ़ायर होने वाली टिप्पणी / संदेश की प्लेटफ़ॉर्म आईडी
`{{comment_sent_at}}`	घटना का ISO 8601 टाइमस्टैम्प (जब उपलब्ध हो)
`{{matched_keyword}}`	मेल खाने वाला कीवर्ड (या `dm_reaction` के लिए इमोजी स्ट्रिंग)
`{{platform}}`	प्लेटफ़ॉर्म पहचानकर्ता: `instagram` या `facebook`
`{{trigger_type}}`	ट्रिगर प्रकार (जैसे `comment_keyword`)

कोई sender_email / recipient_email नहीं। ये जानबूझकर सामने नहीं लाए गए हैं — किसी अजनबी को DM में आपकी बिलिंग ईमेल का कोई वैध स्थान नहीं है, और Meta किसी भी IG वेबहुक पर प्राप्तकर्ता की ईमेल प्रदान नहीं करता है। प्लेसहोल्डर्स से बचना आकस्मिक प्रकटीकरण को रोकता है।

उदाहरण टेम्प्लेट:

Hey {{recipient_username}}, thanks for the comment "{{comment_text}}" — here is the link you wanted: https://example.com

दर सीमाएँ और कैप्स

Plan	सक्रिय ऑटोमेशन (प्रति प्रोफ़ाइल)	दैनिक DM कैप (प्रति खाता)
Launch & Business	10	1,000
Enterprise	50	5,000

सक्रिय-ऑटोमेशन कैप को प्रति User Profile गिना जाता है, प्रति मूल खाता नहीं। आपके खाते के अंतर्गत प्रत्येक प्रोफ़ाइल को अपना खुद का Launch/Business 10 या Enterprise 50 मिलता है, इसलिए कई प्रोफाइल वाला खाता प्रत्येक पर उतने ही ऑटोमेशन चला सकता है। यह सक्रिय ऑटोमेशन गिनता है और POST (क्रिएट) और PUT पुन:-सक्रियण (active: false → true) दोनों पर लागू किया जाता है, प्रत्येक त्रुटि कोड 470 उत्पन्न करता है। प्रति-प्रोफ़ाइल उच्च सीमा चाहिए? इसे अपने खाते के लिए बढ़ाने के लिए सपोर्ट से संपर्क करें। दैनिक DM कैप प्रति मूल Ayrshare खाते पर लागू होता है, आपके सभी प्रोफाइल में साझा किया जाता है, प्रति-प्रोफ़ाइल सब-कैप के साथ ताकि एक व्यस्त प्रोफ़ाइल पूरे खाते के कोटा को नष्ट न कर सके। जब DM कैप हिट हो जाता है, तो गतिविधि रो स्थिति rate_limited दर्ज करती है और कोई DM नहीं भेजा जाता। मैसेजिंग वार्तालाप सीमा भी लागू होती है। send_dm के लिए प्रोफ़ाइल पर Messaging add-on आवश्यक है, और इसके द्वारा भेजा गया प्रत्येक DM उस प्रोफ़ाइल की मासिक वार्तालाप सीमा में गिना जाता है, ठीक वैसे ही जैसे आपके द्वारा स्वयं भेजा गया DM। सीमा पूरी होने पर, किसी नए प्राप्तकर्ता को send_dm नहीं भेजा जाता और गतिविधि रो स्थिति failed दर्ज करती है, साथ ही actionResults[].errorDetails में सीमा संदेश होता है। किसी टिप्पणी द्वारा ट्रिगर किए गए DM (comment_keyword और story_comment) अपवाद हैं: वे सीमा पर भी भेजे जाते हैं, और फिर भी गिने जाते हैं। एक ऑटोमेशन पर संरचनात्मक कैप्स: 1–50 ट्रिगर्स, 1–50 क्रियाएँ। Instagram स्वयं प्रति खाता लगभग 200/घंटा पर DM को सीमित करता है। इसके नीचे सुरक्षित रूप से रहने के लिए इंजन 20–60 सेकंड जिटर के साथ डिस्पैच को गति देता है।

गतिविधि स्थितियाँ

GET /automations/:id/activity में एक रो एक शीर्ष-स्तरीय status और actionResults[] के अंदर एक प्रति-क्रिया status ले जाता है:

Status	अर्थ
`pending`	अभी लिखा गया; कार्यकर्ता ने अभी तक इसे नहीं उठाया
`in_flight`	कार्यकर्ता वर्तमान में डिस्पैच कर रहा है
`sent`	कम से कम एक क्रिया प्लेटफ़ॉर्म द्वारा स्वीकार की गई, और किसी ने प्रमाणीकरण त्रुटि नहीं मारी। `send_dm` के लिए इसका अर्थ है कि Meta ने संदेश स्वीकार किया — यह नहीं कि प्राप्तकर्ता को यह मिला (नीचे दिया गया नोट देखें)
`failed`	कोई भी क्रिया स्वीकार नहीं की गई, और कम से कम एक प्लेटफ़ॉर्म द्वारा अस्वीकार कर दी गई या नहीं चल सकी (और किसी ने भी प्रमाणीकरण त्रुटि नहीं मारी)। कारण `actionResults[].errorDetails` पर होता है
`auth_error`	खाते के Instagram या Facebook Page क्रेडेंशियल या मैसेजिंग अनुमतियों का उपयोग नहीं किया जा सका — उदाहरण के लिए एक समाप्त या रद्द किया गया एक्सेस टोकन, गुम Facebook Page चयन, या प्रोफ़ाइल के लिए Messaging सक्रिय न होना। DM का पुनः प्रयास नहीं किया गया। प्रति-प्राप्तकर्ता डिलीवरी विफलताएँ यहाँ नहीं, बल्कि `failed` के रूप में दर्ज की जाती हैं
`rate_limited`	दैनिक DM कैप (टियर या प्रति-प्रोफ़ाइल) हिट हुआ; कोई DM नहीं भेजा गया
`deduplicated`	यह क्रिया पहले से ही अपनी डेडअप विंडो के भीतर इस प्राप्तकर्ता को फ़ायर हो चुकी है
`skipped`	ऑटोमेशन को डिस्पैच से पहले दबा दिया गया — यह फैन-आउट और डिस्पैच के बीच निष्क्रिय हो गया या हटा दिया गया, इसमें कोई क्रिया कॉन्फ़िगर नहीं है, या इसे ट्रिगर करने वाला एंगेजमेंट ऑटोमेशन के अपने ही खाते से आया — सबसे अधिक बार आपकी अपनी पोस्ट पर एक टिप्पणी। उस अंतिम मामले में कोई क्रिया नहीं चलती: कोई DM नहीं (एक खाता स्वयं को संदेश नहीं भेज सकता), और न ही कोई `fire_webhook` या `send_email`। जिस ऑटोमेशन ने `automation.completed` में ऑप्ट-इन किया है, उसे वह घटना अब भी मिलती है, इसी स्थिति के साथ

pending और in_flight क्षणिक हैं; बाकी सब कुछ अंतिम है। जब किसी ऑटोमेशन में एक से अधिक क्रियाएँ हों, तो शीर्ष-स्तरीय status प्रति-क्रिया परिणामों से इस क्रम में व्युत्पन्न होता है: auth_error यदि किसी क्रिया को प्रमाणीकरण त्रुटि मिली, फिर sent यदि कोई क्रिया स्वीकार की गई, फिर deduplicated यदि हर क्रिया डुप्लीकेटेड हुई, फिर skipped यदि हर क्रिया जानबूझकर दबाई गई (skipped या deduplicated), अन्यथा failed। प्रति-क्रिया विवरण के लिए actionResults[] पढ़ें।

sent एक प्लेटफ़ॉर्म-स्वीकृति रसीद है, डिलीवरी रसीद नहीं। एक send_dm क्रिया को उस क्षण sent के रूप में चिह्नित किया जाता है जब Meta संदेश स्वीकार करता है, चाहे वह आपके Instagram खाते से भेजा गया हो या आपके Facebook Page से Messenger के ज़रिए। ऑटोमेशन केवल यह स्वीकृति दर्ज करता है; वह डिलीवरी को ट्रैक नहीं करता। Instagram किसी भी API पर संदेश डिलीवरी उजागर नहीं करता, और प्राप्तकर्ता को यह वास्तव में मिलता है या नहीं, यह उनकी Instagram Message requests सेटिंग पर निर्भर करता है, जिसे Ayrshare पढ़ या प्रभावित नहीं कर सकता। देखें Automation DM Sent but Not Delivered।

त्रुटि कोड

API दो आकार की त्रुटियाँ लौटाता है:

व्यवसाय-नियम त्रुटियाँ एक नंबरित ऑटोमेशन code ले जाती हैं (जैसे { "action": "automation", "code": 469, ... })।
सत्यापन त्रुटियाँ — कोई भी विकृत अनुरोध बॉडी (गुम या अमान्य फ़ील्ड, अज्ञात टेम्प्लेट वेरिएबल, अनजान कुंजियाँ) — एक details ऑब्जेक्ट के साथ एकल 473 प्रतिक्रिया के रूप में लौटाई जाती हैं जो आपत्तिजनक फ़ील्ड सूचीबद्ध करती हैं। details सत्यापनकर्ता का आउटपुट है (formErrors प्लस fieldErrors). प्रति-शर्त कोड पर नहीं, details पर ब्रांच करें। fieldErrors में, कुंजियाँ शीर्ष-स्तरीय अनुरोध फ़ील्ड हैं (triggers, actions): किसी विशिष्ट प्रविष्टि के भीतर एक समस्या, जैसे कि एक ट्रिगर जिसमें अपने keywords गायब हैं, उस फ़ील्ड (जैसे triggers) के तहत रिपोर्ट की जाती है, जबकि formErrors अनजान कुंजियों जैसे ऑब्जेक्ट-स्तरीय मुद्दे रखता है।

Code	HTTP	अर्थ
468	403	Business या Enterprise योजना आवश्यक
469	404	ऑटोमेशन नहीं मिला (जब कॉलर इसका मालिक नहीं है तब भी लौटाया जाता है)
470	429	आपकी योजना टियर के लिए सक्रिय ऑटोमेशन कैप तक पहुँच गया
471	400	इस प्रोफ़ाइल के लिए अनुरोधित प्लेटफ़ॉर्म पर कोई सोशल खाता लिंक नहीं है
472	403	आपके खाते पर सुविधा अभी उपलब्ध नहीं है — प्रारंभिक पहुँच के लिए हमसे संपर्क करें
473	400	सत्यापन विफल हुआ (विकृत अनुरोध बॉडी) — `details` का निरीक्षण करें

Launch योजनाएँ भी शामिल हैं। Business Launch को Business टियर के रूप में गिना जाता है, इसलिए ऑटोमेशन Launch, Business और Enterprise योजनाओं पर उपलब्ध हैं। 468 केवल उन योजनाओं को लौटाया जाता है जिनमें ऑटोमेशन शामिल नहीं है।

Meta क्या अनुमति नहीं देता

कुछ सामान्य रूप से अनुरोधित क्षमताएँ समर्थित नहीं हैं क्योंकि Meta उन्हें सार्वजनिक Instagram API पर अनुमति नहीं देता है:

नए फ़ॉलोअर्स पर ऑटो-DM. Instagram एक फ़ॉलो वेबहुक प्रकाशित नहीं करता है।
अजनबियों को पहला-संदेश DM. Meta को व्यवसाय खाते द्वारा उन्हें संदेश भेजने से पहले प्राप्तकर्ता के पहले एंगेज करने की आवश्यकता होती है (टिप्पणी, उत्तर, DM, प्रतिक्रिया)। हर समर्थित ट्रिगर ऐसे एंगेजमेंट पर एंकर्ड है — लेकिन ध्यान दें कि भेजने की अनुमति होना संदेश के डिलीवर होने के समान नहीं है: प्राप्तकर्ता की Instagram Message requests सेटिंग अभी भी Meta को संदेश स्वीकार करने और फिर उसे चुपचाप छोड़ देने का कारण बन सकती है (देखें Automation DM Sent but Not Delivered)।
बल्क आउटबाउंड कैंपेन. प्रति घंटा DM कैप्स और एंटी-दुरुपयोग हेयुरिस्टिक्स प्लेटफ़ॉर्म स्तर पर लागू होते हैं।

मल्टी-प्रोफ़ाइल उपयोग

एंडपॉइंट profileKey हेडर का सम्मान करते हैं। एक चाइल्ड प्रोफ़ाइल की कुंजी पास करें और ऑटोमेशन उस प्रोफ़ाइल के तहत बनाया/प्रबंधित किया जाता है। दर सीमाएँ प्रति-प्रोफ़ाइल सब-कैप के माध्यम से प्रोफाइल में विभाजित होती हैं ताकि एक चैटर प्रोफ़ाइल मूल खाते के कोटा को नष्ट न करे।

अक्सर पूछे जाने वाले प्रश्न

क्या मैं नए फ़ॉलोअर पर ट्रिगर कर सकता हूँ?

नहीं। Instagram एक फ़ॉलो वेबहुक प्रकाशित नहीं करता है, और Meta तीसरे-पक्ष के ऐप्स को उस उपयोगकर्ता को DM भेजने की अनुमति नहीं देता है जिसने पहले एंगेज नहीं किया है। हर समर्थित ट्रिगर (comment_keyword, story_reply, dm_reaction, dm_keyword) ऐसे एंगेजमेंट पर एंकर्ड है, जो भेजने को अनुमेय बनाता है।

कोई गतिविधि sent कहती है लेकिन प्राप्तकर्ता को DM कभी नहीं मिला — ऐसा क्यों?

sent का अर्थ है कि Meta ने संदेश स्वीकार किया, यह नहीं कि यह डिलीवर हुआ। यह Instagram और Facebook (आपके Page से Messenger), दोनों पर लागू होता है: ऑटोमेशन केवल स्वीकृति दर्ज करता है और डिलीवरी को ट्रैक नहीं करता। Instagram पर, डिलीवरी प्राप्तकर्ता की Instagram Message requests सेटिंग पर निर्भर करती है — यदि वे सभी से मैसेज रिक्वेस्ट की अनुमति नहीं देते हैं, तो Meta सफलता प्रतिक्रिया लौटाता है और संदेश को चुपचाप छोड़ देता है, बिना किसी त्रुटि, वेबहुक, या किसी भी API सतह पर अन्य संकेत के। एक सफल टिप्पणी-ट्रिगर्ड DM भी एक मैसेज रिक्वेस्ट के रूप में पहुँचता है जिसे प्राप्तकर्ता को स्वीकार करना होगा (जब तक कि पहले से कोई बातचीत मौजूद न हो)। यह एक स्थायी Instagram प्लेटफ़ॉर्म सीमा है। देखें Automation DM Sent but Not Delivered।

जब ऑटोमेशन फ़ायर होता है और मेरा एक्सेस टोकन अमान्य होता है तो क्या होता है?

यदि खाते के Instagram या Facebook Page क्रेडेंशियल या मैसेजिंग अनुमतियाँ वास्तव में विफल होती हैं — उदाहरण के लिए एक समाप्त या रद्द किया गया एक्सेस टोकन, गुम Facebook Page चयन, या प्रोफ़ाइल के लिए Messaging सक्रिय न होना — तो गतिविधि रो स्थिति auth_error दर्ज करती है और DM का पुनः प्रयास नहीं किया जाता है। खाते की स्थिति को हल करने से (फिर से लिंक करना, कोई Page चुनना, या Messaging सक्रिय करना) अगले मिलान करने वाले एंगेजमेंट को सामान्य रूप से फ़ायर होने देता है। यह केवल वास्तविक क्रेडेंशियल और अनुमति विफलताओं पर लागू होता है: यदि कोई विशिष्ट DM किसी अन्य कारण से डिलीवर नहीं किया जा सका — उदाहरण के लिए प्राप्तकर्ता नहीं मिल सका, या ट्रिगर करने वाला एंगेजमेंट उस खाते से आया जो DM भेजता — तो रो को failed या skipped के रूप में दर्ज किया जाता है जिसमें कारण actionResults[].errorDetails पर होता है, और फिर से लिंक करने से परिणाम नहीं बदलेगा।

DM भेजे जाने से पहले देरी क्यों है?

Instagram के एंटी-स्पैम सिस्टम को DM भेजना ऑर्गैनिक लगे, इसके लिए प्रत्येक डिस्पैच एंगेजमेंट के 20–60 सेकंड बाद शेड्यूल किया जाता है। यह देरी किसी भी नियम के मिलान से पहले एंगेजमेंट पर लागू होती है, इसलिए यह नियम की हर क्रिया पर लागू होती है, fire_webhook और send_email सहित — आपका वेबहुक कमेंट के 20–60 सेकंड बाद पहुँचेगा, तुरंत नहीं। गतिविधि रो का created टाइमस्टैम्प तब होता है जब ट्रिगर मिला; completedAt तब होता है जब डिस्पैच समाप्त हुआ।

क्या गतिविधि रो हमेशा के लिए रखे जाते हैं?

ट्रेस और एनालिटिक्स के लिए गतिविधि रो अनिश्चितकालीन रूप से बनाए रखे जाते हैं। प्रदर्शन के लिए GET /automations/:id/activity एंडपॉइंट पिछले 30 दिनों के रो लौटाता है। (डेडअप गार्ड अपनी खुद की प्रति-क्रिया विंडो का उपयोग करता है — डिफ़ॉल्ट 7 दिन — जो गतिविधि लुकबैक से असंबंधित है।)

क्या ऑटोमेशन हटाने से इसकी गतिविधि इतिहास हट जाता है?

नहीं। हटाना एक सॉफ्ट-डिलीट है: मास्टर रो को deleted के रूप में चिह्नित किया जाता है, कोई नई डिस्पैच नहीं होती है, लेकिन ऐतिहासिक गतिविधि रो गतिविधि एंडपॉइंट के माध्यम से पठनीय रहती हैं।

एंडपॉइंट

POST /automations — एक नया ऑटोमेशन बनाएँ
GET /automations — अपने ऑटोमेशन सूचीबद्ध करें
GET /automations/:id — इसके ट्रिगर और क्रियाओं के साथ एक ऑटोमेशन प्राप्त करें
PUT /automations/:id — आंशिक अपडेट; active: false के माध्यम से रोकें
DELETE /automations/:id — सॉफ्ट-डिलीट
GET /automations/:id/activity — कर्सर-पेजिनेटेड डिस्पैच ऑडिट लॉग

Get Started

API Endpoints

Multiple Users

Dashboard

Additional

Automations API अवलोकन

यह कैसे काम करता है

Triggers

`"all"` के साथ एवरग्रीन नियम

Facebook Pages

Actions

प्रति-क्रिया डेडअप विंडो

डायनामिक संदेश सामग्री

वेबहुक घटनाएँ

`automation.triggered`

`automation.completed`

यदि कोई वेबहुक रजिस्टर नहीं है

टेम्प्लेट वेरिएबल्स

दर सीमाएँ और कैप्स

गतिविधि स्थितियाँ

त्रुटि कोड

Meta क्या अनुमति नहीं देता

मल्टी-प्रोफ़ाइल उपयोग

अक्सर पूछे जाने वाले प्रश्न

एंडपॉइंट

​यह कैसे काम करता है

​Triggers

​"all" के साथ एवरग्रीन नियम

​Facebook Pages

​Actions

​प्रति-क्रिया डेडअप विंडो

​डायनामिक संदेश सामग्री

​वेबहुक घटनाएँ

​automation.triggered

​automation.completed

​यदि कोई वेबहुक रजिस्टर नहीं है

​टेम्प्लेट वेरिएबल्स

​दर सीमाएँ और कैप्स

​गतिविधि स्थितियाँ

​त्रुटि कोड

​Meta क्या अनुमति नहीं देता

​मल्टी-प्रोफ़ाइल उपयोग

​अक्सर पूछे जाने वाले प्रश्न

​एंडपॉइंट

यह कैसे काम करता है

Triggers

`"all"` के साथ एवरग्रीन नियम

Facebook Pages

Actions

प्रति-क्रिया डेडअप विंडो

डायनामिक संदेश सामग्री

वेबहुक घटनाएँ

`automation.triggered`

`automation.completed`

यदि कोई वेबहुक रजिस्टर नहीं है

टेम्प्लेट वेरिएबल्स

दर सीमाएँ और कैप्स

गतिविधि स्थितियाँ

त्रुटि कोड

Meta क्या अनुमति नहीं देता

मल्टी-प्रोफ़ाइल उपयोग

अक्सर पूछे जाने वाले प्रश्न

एंडपॉइंट