Channel Endpoints
Last updated
Endpoints for the Telegram and Discord channels.
| Method | Path | Description |
|---|---|---|
GET | /v1/channel | local — every channel read in one object: telegram and discord each carry {enabled, username, has_token}, and admin carries {channel, authorized, chats:[{value,type,id,name}]}. chats comes from the .telegram / .discord auth files (tg first, then dc) and each value can be posted back as-is; authorized says whether the current relay target is still on that list (a hand-typed ID reads false) |
POST | /v1/channel/telegram · /v1/channel/discord | local — {action:"enable"|"disable", token?}. Enable requires token (400 otherwise); disable deletes the token from the keychain and clears the flag. Enable stores the token and flips the config flag only; the token check the TUI performs (verifyTelegram starts a bot client and reads its username) is intentionally skipped, since the daemon's config-file watcher already reconnects the bot and fills in its username |
GET | /v1/channel/:channel/chats | local — chats that finished verification for telegram / discord. Only meaningful while the bot runs, so ask for it after the channel reports enabled |
DELETE | /v1/channel/:channel/chat | local — {id}. Drops one chat from that auth file; the chat has to verify again before the bot answers it, and the reply is {ok, removed}. 404 when the id is not on the list or no chat has been authorized yet |
POST | /v1/channel/admin | local — {value:"tg@<chatID>"|"dc@<channelID>"|""}. Sets where new-chat verification codes are relayed; an empty string clears it. value is required (omitting it returns 400 so an empty body cannot silently clear the setting). Only the format is validated — an ID that is not authorized makes the relay log a warning and keep the code log-only |