#webhook received but not taking action

21 messages · Page 1 of 1 (latest)

lime hull
#

openclaw uses a tool that takes some time so instead it passes a webhook , to knwo when its done so it can follow up and update me , but it never does even though it receives the webhook updates

clever brookBOT
modest radishBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

clever brookBOT
bold etherBOT
#

Yep, that usually means the webhook part works, but the completion delivery path is broken.

For async/background work, OpenClaw needs all 3 of these to line up:

  • the task reaches a terminal state
  • the task is still bound to the original session and requesterOrigin
  • if direct send fails, the session-queued + heartbeat wake path still works

So if you see the webhook being received, but no follow-up message, the usual failure modes are:

  • deliveryStatus: parent_missing → task was not bound to the originating session/origin
  • deliveryStatus: failed → Discord send failed
  • deliveryStatus: session_queued → direct send fell back to session queue, but heartbeat got skipped/deferred
  • older routing bug → stored lastChannel / lastTo got overwritten, so completion had nowhere good to go

Please paste these:

# 
openclaw --version
openclaw status --all
openclaw tasks show <taskId-or-runId-or-sessionKey>
openclaw tasks audit

And check logs for these lines:

openclaw logs --follow

Look for:

  • webhook received
  • webhook processed
#
  • Failed to deliver background task update
  • Failed to queue background task session delivery
  • heartbeat skipped
  • requests-in-flight

If this is your own plugin/tool, the big gotcha is this: receiving the webhook is not enough. The task/flow must be created from tool context, or rebound later with a trusted stored session binding, so OpenClaw knows which chat to wake.

Relevant docs:

If you paste the tasks show output, I can probably tell which branch it’s failing on pretty quickly.

lime hull
bold etherBOT
#

Easiest way, don’t hunt the session key first, just grab the task ID.

Run:

openclaw tasks list

That list includes columns for:

  • Task ID
  • Run ID
  • Child Session

Then use the Task ID directly:

# 
openclaw tasks show <taskId>

If you want the raw fields:

openclaw tasks list --json

If you’re already in the same chat/thread, /tasks can also show the active background task.

So basically:

  • run id → from openclaw tasks list
  • session key → often visible in task details after openclaw tasks show <taskId>
  • best first step → use the task id, since tasks show accepts that too
#

If you paste the output of openclaw tasks list, I can tell you exactly which value to use.

lime hull
bold etherBOT
#

Ah, that’s the clue.

If openclaw tasks list is empty, then OpenClaw is not tracking that job as a background task. In that state, the webhook can arrive, but there’s nothing for OpenClaw to wake/follow up from.

So this is usually one of these:

  • custom tool/plugin: it receives the webhook, but never created or bound a task/flow to the original session
  • the work started outside a real session, so no sessionKey / requesterOrigin was captured
  • older version / bug, if this is supposed to be a built-in async path

Important bit: built-in follow-up does not happen automatically just because a webhook was received.

If this is your own tool, you usually need to create/bind it from tool context, for example:

  • api.runtime.taskFlow.fromToolContext(ctx)
  • or later bindSession({ sessionKey, requesterOrigin }) from trusted stored state
#

If it’s a built-in tool and you still get 0 tasks, that’s not expected.

Can you paste:

openclaw --version

and tell me which tool/plugin is doing the webhook callback?

If you can also grab the matching log lines around the callback, even better:

openclaw logs --follow

and look for webhook received / webhook processed.

#

That’ll tell us pretty fast if this is “webhook handled, but no task bound” vs an actual bug.

lime hull
bold etherBOT
#

Yep, that warning is probably the problem.

OpenClaw is saying it skipped the joblisten webhook route entirely because this secret could not be resolved:

plugins.entries.webhooks.routes.joblisten.secret -> env:default:OPENCLAW_WEBHOOK_SECRET

So if that’s the route you expect callbacks on, it is not actually active.

Fix

Make sure OPENCLAW_WEBHOOK_SECRET is set in the Gateway process environment, then restart the gateway:

openclaw gateway restart

Then check that the warning is gone.

#

Important gotcha

If you’re running OpenClaw as a service, setting the env var in your current shell is often not enough. It has to exist where the gateway service starts.

What to verify next

  1. set OPENCLAW_WEBHOOK_SECRET
  2. restart gateway
  3. confirm you no longer see:
skipping route joblisten ... OPENCLAW_WEBHOOK_SECRET
  1. then retry the webhook flow

If you want, paste how you’re setting OPENCLAW_WEBHOOK_SECRET and I can tell you if it’s being set in the wrong place. Docs: https://docs.openclaw.ai/plugins/webhooks

lime hull
bold etherBOT
#

Yep, same warning, same root cause.

joblisten is still disabled. OpenClaw is not resolving OPENCLAW_WEBHOOK_SECRET, so that webhook route never gets registered.

So until this warning disappears, that webhook path will not work.

Fast sanity check

Temporarily replace the SecretRef with a literal string for that route:

plugins: {
  entries: {
    webhooks: {
      enabled: true,
      config: {
# 
        routes: {
          joblisten: {
            // ...
            secret: "some-test-secret"
          }
        }
      }
    }
  }
}

Then restart: