Routes configureren
Stel de configuratie in onderplugins.entries.webhooks.config:
secret accepteert een platte tekenreeks of een SecretRef: { source: "env" | "file" | "exec", provider: "default", id: "..." }.
SecretRefs worden omgezet in de momentopname van de opstartconfiguratie van de Gateway. Wanneer het
secret van één route niet kan worden omgezet, blijft de Gateway actief en blijft precies die route
geregistreerd maar inactief: verzoeken ontvangen een algemene authenticatiefout (401).
Andere routes blijven beschikbaar. Herstel de SecretRef-bron en laad of start vervolgens
de Gateway opnieuw om de nieuwe momentopname te activeren. SecretRef-waarden worden nooit omgezet
in het openbare aanvraagpad.
Beveiligingsmodel
Elke route handelt met de TaskFlow-bevoegdheid van de geconfigureerdesessionKey: de route
kan elke TaskFlow waarvan die sessie eigenaar is inspecteren en wijzigen. TaskFlow-toegang
verloopt altijd via api.runtime.tasks.managedFlows.bindSession(...), zodat een
route nooit buiten de gekoppelde sessie kan handelen. Om de impact te beperken:
- Gebruik voor elke route een sterk, uniek secret.
- Geef de voorkeur aan een SecretRef boven een inline secret in platte tekst.
- Koppel routes aan de meest beperkte sessie die bij de workflow past.
- Stel alleen het specifieke webhookpad beschikbaar dat je nodig hebt.
POST)
en Content-Type: application/json, vervolgens een frequentielimiet met een vast tijdvenster (120
verzoeken per venster van 60 seconden per sleutelcombinatie van pad en client-IP, met maximaal 4,096 bijgehouden
sleutels), vervolgens beperking van actieve verzoeken (8 gelijktijdige verzoeken per sleutel, met maximaal
4,096 bijgehouden sleutels), vervolgens authenticatie met het gedeelde secret en daarna het lezen van een JSON-body
van 256 KB met een limiet van 15 seconden. Verzoeken die niet slagen voor een eerdere controle bereiken
de latere controles nooit.
Verzoekindeling
VerzendPOST-verzoeken met Content-Type: application/json en
Authorization: Bearer <secret> of x-openclaw-webhook-secret: <secret>:
Ondersteunde acties
Wijzigingsacties (
set_waiting, resume_flow, finish_flow, fail_flow,
request_cancel) vereisen flowId en expectedRevision voor optimistische
gelijktijdigheidscontrole; een verouderde revisie retourneert 409 revision_conflict.
create_flow
run_task
Toegestane waarden voor runtime: subagent, acp. startedAt, lastEventAt en
progressSummary zijn alleen geldig wanneer status gelijk is aan "running"; als je ze
met een andere status verzendt, wordt 400 invalid_request geretourneerd.
Antwoordstructuur
sessionKey van de route niet kunnen lekken. Waarden voor code zijn onder meer not_found,
not_managed, revision_conflict, persist_failed, cancel_requested,
cancel_pending, terminal, invalid_request, request_rejected en
actiespecifieke terugvalcodes (mutation_rejected, create_rejected,
task_not_created, cancel_rejected) wanneer een wijziging wordt geweigerd om een
reden die niet door de bovengenoemde benoemde codes wordt gedekt.
Gerelateerd
- Hooks - interne gebeurtenisgestuurde hooks tegenover deze HTTP-gebaseerde TaskFlow-bridge
- Gateway-webhooks (
hooks.*-configuratie) - afzonderlijke generieke HTTP-endpointfunctie van de Gateway; niet hetzelfde als de routes van deze plugin - Runtime-SDK voor plugins
- CLI-webhooks