रूट कॉन्फ़िगर करें
कॉन्फ़िगरेशन कोplugins.entries.webhooks.config के अंतर्गत सेट करें:
secret सादा स्ट्रिंग या SecretRef स्वीकार करता है: { source: "env" | "file" | "exec", provider: "default", id: "..." }।
SecretRefs का समाधान Gateway के स्टार्टअप कॉन्फ़िगरेशन स्नैपशॉट में किया जाता है। जब किसी रूट के
सीक्रेट का समाधान नहीं हो पाता, तो Gateway चलता रहता है और वही रूट
पंजीकृत लेकिन निष्क्रिय रहता है: अनुरोधों को सामान्य प्रमाणीकरण विफलता मिलती है (401)।
अन्य रूट उपलब्ध रहते हैं। SecretRef स्रोत ठीक करें, फिर नया स्नैपशॉट सक्रिय
करने के लिए Gateway को रीलोड या पुनः आरंभ करें। सार्वजनिक अनुरोध पथ पर
SecretRef मानों का समाधान कभी नहीं किया जाता।
सुरक्षा मॉडल
प्रत्येक रूट अपने कॉन्फ़िगर किए गएsessionKey के TaskFlow अधिकार के साथ कार्य करता है: यह
उस सेशन के स्वामित्व वाले किसी भी TaskFlow का निरीक्षण और परिवर्तन कर सकता है। TaskFlow एक्सेस
हमेशा api.runtime.tasks.managedFlows.bindSession(...) के माध्यम से होता है, इसलिए कोई
रूट कभी भी अपने संबद्ध सेशन के बाहर कार्य नहीं कर सकता। प्रभाव क्षेत्र सीमित करने के लिए:
- प्रत्येक रूट के लिए एक मजबूत, अद्वितीय सीक्रेट उपयोग करें।
- इनलाइन सादे टेक्स्ट वाले सीक्रेट के बजाय SecretRef को प्राथमिकता दें।
- रूट को वर्कफ़्लो के अनुकूल सबसे सीमित सेशन से संबद्ध करें।
- केवल वही विशिष्ट Webhook पथ उपलब्ध कराएँ जिसकी आपको आवश्यकता है।
POST) और
Content-Type: application/json जाँच, फिर निश्चित-विंडो दर सीमांकन (प्रत्येक path+client-IP कुंजी पर प्रति 60-सेकंड विंडो में 120
अनुरोध, अधिकतम 4,096 ट्रैक की गई
कुंजियाँ), फिर प्रगति पर मौजूद अनुरोधों की सीमा (प्रति कुंजी 8 समवर्ती अनुरोध, अधिकतम
4,096 ट्रैक की गई कुंजियाँ), फिर साझा-सीक्रेट प्रमाणीकरण, फिर 256 KB /
15-सेकंड की JSON बॉडी रीड। किसी शुरुआती जाँच में विफल होने वाले अनुरोध
बाद की जाँचों तक कभी नहीं पहुँचते।
अनुरोध प्रारूप
Content-Type: application/json और Authorization: Bearer <secret> या x-openclaw-webhook-secret: <secret> में से किसी एक के साथ
POST अनुरोध भेजें:
समर्थित क्रियाएँ
परिवर्तनकारी क्रियाओं (
set_waiting, resume_flow, finish_flow, fail_flow,
request_cancel) को आशावादी समवर्ती नियंत्रण के लिए flowId और expectedRevision
की आवश्यकता होती है; कोई पुराना संशोधन 409 revision_conflict लौटाता है।
create_flow
run_task
अनुमत runtime मान: subagent, acp। startedAt, lastEventAt, और
progressSummary केवल तभी मान्य हैं जब status, "running" हो; उन्हें
किसी अन्य स्थिति के साथ भेजने पर 400 invalid_request लौटता है।
प्रतिक्रिया संरचना
sessionKey को लीक नहीं कर सकतीं। code मानों में not_found,
not_managed, revision_conflict, persist_failed, cancel_requested,
cancel_pending, terminal, invalid_request, request_rejected, और
क्रिया-विशिष्ट फ़ॉलबैक कोड (mutation_rejected, create_rejected,
task_not_created, cancel_rejected) शामिल हैं, जब कोई परिवर्तन ऐसे
कारण से अस्वीकार किया जाता है जिसे ऊपर दिए गए नामित कोड में शामिल नहीं किया गया है।
संबंधित
- हुक्स - आंतरिक घटना-संचालित हुक्स बनाम यह HTTP-आधारित TaskFlow ब्रिज
- Gateway Webhooks (
hooks.*कॉन्फ़िगरेशन) - अलग सामान्य Gateway HTTP एंडपॉइंट सुविधा; इस Plugin के रूट के समान नहीं - Plugin रनटाइम SDK
- CLI Webhooks