call-baxter + tg interoperability¶
Recommended split¶
Keep the projects separate:
call-baxter- generic daemon / CLI / rule engine
- webhook ingress, pollers, schedules, and rule execution
tg-agent-cli- Telegram projection store
- browse-first CLI for chats, messages, callbacks, media, and actions
tg-agent-cli does not need a resident daemon for this integration model.
The Telegram plugin inside call-baxter can receive webhook payloads or polled updates, persist those updates into the Telegram projection database immediately, and then emit the normalized telegram.* events that rules match on.
Flow¶
Telegram webhook or poller
-> call-baxter telegram plugin shared update pipeline
-> persist raw update into tg projection db (optional but recommended)
-> emit telegram.message.* / telegram.callback_query.new / telegram.media.present / telegram.message.reaction
-> generic call-baxter rules match on telegram.*
Plugin config example¶
plugins:
- call_baxter.plugins.system
- module: call_baxter.plugins.telegram
config:
bot_token: "123456:abc"
api_base: "https://api.telegram.org"
projection_database_url: ./tg-state.db
projection_media_storage_mode: file
projection_media_base_dir: ./media
Optional direct persist action¶
The plugin still exposes telegram.persist_update as an explicit action for manual or nonstandard flows, but the default interoperable path is to let the plugin persist before event publication.
Event types contributed by the Telegram plugin¶
telegram.message.newtelegram.message.editedtelegram.channel_post.newtelegram.channel_post.editedtelegram.business_message.newtelegram.business_message.editedtelegram.callback_query.newtelegram.media.presenttelegram.message.reaction
telegram.callback_query.new represents an incoming button press / callback query. It carries the callback query id plus the callback data payload and, when Telegram supplied a parent message, the originating chat/message refs. That makes it the event to match when you want to answer a callback query, branch on button data, or correlate the press with the message that contained the inline keyboard.
Poller¶
The plugin also contributes:
telegram.updates
If offset is not given explicitly and a Telegram projection database is configured, the poller derives offset = max(update_id) + 1 from the projection DB so repeated schedule runs stay incremental.
Wildcards and propagation¶
The runtime supports wildcard rule kinds such as telegram.* through shell-style matching, and an event can set cancel_propagation: true to stop matching after the first rule chain finishes.
Replacing a TGEX deployment¶
For the compatibility launcher, legacy environment variables and routes, WordPress parity, cutover checklist, and rollback procedure, see Replace TGEX with Call Baxter.