#How and where to find the description of all the rpc calls

1 messages · Page 1 of 1 (latest)

earnest flower
#

I am looking for the descrption of rcp all exposed and params it accepts on for example:
openclaw gateway call exec.approval.list --params '{"id": "5656179904"}'

🦞 OpenClaw 2026.5.12 (f066dd2) — I'm basically a Swiss Army knife, but with more opinions and fewer sharp edges.

│
â—‡
Gateway call: exec.approval.list
[]....I can see lot of rpc calls on the debug of manual rpc b

buoyant tideBOT
#

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

agile boughBOT
# earnest flower I am looking for the descrption of rcp all exposed and params it accepts on for...

There isn’t currently a polished “all Gateway RPC methods + every param schema” reference page. The closest documented index is the Gateway protocol page: https://docs.openclaw.ai/gateway/protocol

A few useful facts from the current source/docs:

  • The conservative method discovery list is sent in the WS handshake as hello-ok.features.methods.
  • That list comes from src/gateway/server-methods-list.ts, plus loaded plugin/channel gateway methods.
  • Param schemas live mostly under src/gateway/protocol/schema/*.ts, with handler implementations under src/gateway/server-methods/*.ts.
  • The docs page explicitly says the method-family section is not a generated dump, so source is still the truth for exact params.

For your specific example: exec.approval.list does not take an id; it returns all currently pending exec approvals. So this is enough:

openclaw gateway call exec.approval.list --params '{}'

An empty [] just means there are no pending exec approvals right now.

agile boughBOT
# earnest flower I am looking for the descrption of rcp all exposed and params it accepts on for...

If you want one approval by id, use:

openclaw gateway call exec.approval.get --params '{"id":"5656179904"}'

For the approval family, the relevant params are roughly:

exec.approval.get      { "id": string }
exec.approval.list     {}
exec.approval.resolve  { "id": string, "decision": "allow-once" | "allow-always" | "deny" }
exec.approval.request  { command/cwd/host/nodeId/etc.; mostly internal plumbing }

If you’re exploring from a source checkout, start here:

agile boughBOT
earnest flower
#

when i run anujsharma@Anuj-Mac .openclaw % openclaw gateway call exec.approval.list

🦞 OpenClaw 2026.5.12 (f066dd2) — If something's on fire, I can't extinguish it—but I can write a beautiful postmortem.

│
â—‡
Gateway call: exec.approval.list
[]....i see emput value when my tlegram has faled due excessive approvals i dont want to fix this by clearing the approval

agile boughBOT
# earnest flower when i run anujsharma@Anuj-Mac .openclaw % openclaw gateway call exec.approval.l...

exec.approval.list only shows currently pending in-memory approval requests. So [] means “nothing is waiting for approval right now”, not “Telegram approval state is healthy”.

A few likely cases:

  • the approval already expired; pending exec approvals expire after ~30 minutes
  • the approval route failed before it could stay pending / be delivered
  • the agent retried and hit approval spam/failure behavior, but there is no single pending approval left to resolve
  • the failure is Telegram delivery/config, not the approval queue itself

So: you’re right that “clearing approvals” is probably not the fix here.

For Telegram, check these config areas from the docs: https://docs.openclaw.ai/channels/telegram#exec-approvals

channels.telegram.execApprovals.enabled
channels.telegram.execApprovals.approvers
agile boughBOT
# earnest flower when i run anujsharma@Anuj-Mac .openclaw % openclaw gateway call exec.approval.l... 
channels.telegram.execApprovals.target
channels.telegram.capabilities.inlineButtons

Approvers need to be numeric Telegram user IDs. Inline buttons also need channels.telegram.capabilities.inlineButtons to allow the target surface, for example dm, group, or all.

The better next diagnostic is logs, not the RPC list:

openclaw logs --follow

Then reproduce the Telegram approval failure and look for lines mentioning exec approval, Telegram, approval route, or delivery failure. If you paste the relevant redacted log lines plus:

agile boughBOT
earnest flower
#

how do i recover from this state
[telegram][diag] spooled update 692745807 handler failed; keeping for retry: GatewayClientRequestError in middleware: unknown or expired approval id
19:34:00
error
channels/telegram
telegram answerCallbackQuery failed: Call to 'answerCallbackQuery' failed! (400: Bad Request: query is too old and response timeout expired or query ID is invalid)
19:34:00
error
channels/telegram
callback handler failed: TelegramRetryableCallbackError: GatewayClientRequestError: unknown or expired approval id

agile boughBOT
# earnest flower how do i recover from this state [telegram][diag] spooled update 692745807 hand...

That state is a stale Telegram callback update being retried. The approval ID is already gone, but the Telegram update did not get marked handled, so polling keeps reprocessing update 692745807. The answerCallbackQuery ... query is too old line is a side effect of retrying an old button click.

Recovery path: advance Telegram’s stored update offset past that stale update, then restart the gateway.

For the default Telegram account on a normal install:

openclaw gateway stop

mkdir -p ~/.openclaw/telegram
cp ~/.openclaw/telegram/update-offset-default.json ~/.openclaw/telegram/update-offset-default.json.bak 2>/dev/null || true

printf '%s
' '{"version":2,"lastUpdateId":692745807,"botId":null}' > ~/.openclaw/telegram/update-offset-default.json

openclaw gateway start
agile boughBOT
# earnest flower how do i recover from this state [telegram][diag] spooled update 692745807 hand...

If you use a named Telegram account, the file is:

~/.openclaw/telegram/update-offset-<accountId>.json

After restart, don’t click the old approval buttons again. Trigger a fresh command/approval instead. If it keeps happening with new approval buttons, then the underlying Telegram exec approval setup still needs fixing: numeric approver IDs, channels.telegram.execApprovals.*, and inline button capability. Docs: https://docs.openclaw.ai/channels/telegram#exec-approvals

Also, this retry behavior for unknown or expired approval id looks bug-worthy; that error probably should be treated as terminal for this callback. If you can reproduce it on 2026.5.12, please file it with those log lines: https://github.com/openclaw/openclaw/issues

earnest flower
#

can you advise whic the erro in the command Docs: gateway/configuration
anujsharma@Anuj-Mac .openclaw % openclaw gateway call channels.stop --params '{"channel":"telegram-default"}'

🦞 OpenClaw 2026.5.12 (f066dd2) — It's not "failing," it's "discovering new ways to configure the same thing wrong."

│
â—‡
Gateway call failed: GatewayClientRequestError: invalid channels.stop channel
anujsharma@Anuj-Mac .openclaw % openclaw gateway call channels.stop --params '{"channel":"Telegram default"}'

🦞 OpenClaw 2026.5.12 (f066dd2) — I'm not saying your workflow is chaotic... I'm just bringing a linter and a helmet.

│
â—‡
Gateway call failed: GatewayClientReque--anujsharma@Anuj-Mac .openclaw % openclaw channels list

🦞 OpenClaw 2026.5.12 (f066dd2) — I don't sleep, I just enter low-power mode and dream of clean diffs.

Chat channels:

  • Telegram default: installed, configured, enabled, token=env

Model provider usage moved out of channels list — see openclaw status or openclaw models list.
Docs: gateway/configuration
stError: invalid channels.stop channel

agile boughBOT
agile boughBOT
# earnest flower can you advise whic the erro in the command Docs: gateway/configuration anujshar... 
openclaw gateway call channels.stop --params '{"channel":"telegram","accountId":"default"}'

Same pattern for start:

openclaw gateway call channels.start --params '{"channel":"telegram","accountId":"default"}'

One caveat: gateway call is a low-level debug surface. In the current docs/source I can see channels.start, channels.logout, and channels.status, but not a documented channels.stop method, so if that still fails after fixing the params, use the supported CLI/config path instead:

openclaw channels remove --channel telegram --account default
openclaw gateway restart