#Workspace plugin HTTP route returns 404 despite successful registration

1 messages · Page 1 of 1 (latest)

astral heart
#

Running OpenClaw 2026.4.24 in Docker on Hetzner Ubuntu 24.04.

Workspace plugin at ~/.openclaw/workspace/plugins/gmail-push/ registers an HTTP route at startup:

api.registerHttpRoute({
path: '/api/webhooks/gmail-push',
auth: 'plugin',
match: 'exact',
async handler(req, res) { ... }
})

openclaw plugins inspect gmail-push confirms the plugin is fully loaded:

Status: loaded
Format: openclaw
Source: ~/.openclaw/workspace/plugins/gmail-push/index.js
Shape: non-capability
HTTP routes: 1

Gateway logs show successful registration on every load:

[gmail-push] Webhook registered at /api/webhooks/gmail-push

But hitting the route directly inside the container returns 404 for all methods, with or without auth:

$ curl -X POST http://localhost:18789/api/webhooks/gmail-push
HTTP/1.1 404 Not Found

registerHttpRoute exists in /app/dist/ and is used by official extensions (webhooks, slack, diffs, nostr). Same plugin worked on a local Mac Docker setup before migrating to Hetzner. Gateway is bound to 0.0.0.0:18789 (non-loopback). Auth is set to "plugin" per the architecture docs for plugin-managed webhook verification.

??? QUESTION: The route appears in the plugin registry (HTTP routes: 1) but the HTTP dispatcher doesn't honor it. Has anyone seen workspace plugin routes register successfully in the registry but silently fail to attach to the dispatcher? Is there a config flag for workspace plugin route dispatch I'm missing?

regal troutBOT
#

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

sweet helmBOT
#

I don’t see a separate config flag for “workspace plugin route dispatch.” If api.registerHttpRoute(...) is in the live Gateway registry, it should be considered by the HTTP dispatcher.

Two important gotchas here:

  1. openclaw plugins inspect is not a live Gateway probe — it does a module-loaded inspection pass. So HTTP routes: 1 proves the plugin can register the route, but not that the currently-serving Gateway process has that route attached. Docs call this out: https://docs.openclaw.ai/cli/plugins#install

  2. 2026.4.24 is suspicious here. There were Gateway/plugin HTTP dispatch startup fixes after that; I’d update to at least 2026.4.26 first, then fully restart the Docker container / actual openclaw gateway run process.

Quick triage I’d do:

openclaw --version
openclaw gateway status --deep --require-rpc
openclaw status --all

Then add a first-line log inside the handler:

# 
async handler(req, res) {
  console.log('[gmail-push] HANDLER HIT', req.method, req.url)
  res.statusCode = 204
  res.end()
  return true
}

If that still returns 404 after updating + full container restart, then yeah, that’s likely a real dispatcher/registry bug and worth filing with the repro: https://github.com/openclaw/openclaw/issues

Minor recommendation: use a non-core-looking path like /plugins/gmail-push or /plugins/webhooks/gmail-push. /api/webhooks/... shouldn’t be silently blocked, but /plugins/... is the convention used by bundled webhook routes.

astral heart
#

Filed: https://github.com/openclaw/openclaw/issues/73747 . Confirmed handler never fires on either /api/webhooks/gmail-push or /plugins/webhooks/gmail-push paths after full container restart with the explicit logging handler. Thanks for the triage path.