Messaging and Event Extensions

此内容尚不支持你的语言。

Messaging and event integrations are extensions. Older code and docs sometimes call them providers, but the current documentation model is an extension pack that offers capabilities through greentic.ext.capabilities.v1.

Messaging Extensions

Messaging extensions connect digital workers to user-facing channels. The documented channel set includes:

WebChat
Slack
Microsoft Teams
Telegram
WhatsApp
Webex
email

A messaging extension usually normalizes inbound channel payloads, routes them to the configured worker or flow, formats outbound replies, and applies tenant/team/channel setup.

Event Extensions

Event extensions kickstart workers from system events instead of a chat message. Common event sources include:

HTTP webhooks
timers and schedules
SendGrid email events
Twilio SMS events
queues
pub/sub topics
audit events
metrics events
custom domain events

An event extension validates inbound event payloads, maps them to Greentic runtime input, starts the configured worker or flow, and emits trace or observer metadata.

Authoring Flow

Author messaging and event extensions with the gtdx CLI. Scaffold a provider extension, iterate with the dev loop, then sign and publish:

gtdx new my-channel --kind provider
gtdx dev

gtdx new --kind provider scaffolds a working wasm32-wasip2 component, its describe.json manifest (the single source of truth for the extension’s metadata, including the capabilities it offers and the operations they map to), and the vendored WIT contract. See Writing Extensions for the end-to-end inner loop.

Setup, Secrets, and Tenancy

Real messaging and event integrations usually need setup questions and secret references:

bot tokens
webhook signing secrets
OAuth client settings
tenant and team routing
allowed domains
channel ids
reply policies
event subscription names

When requires_setup: true, the capability offer must point at setup QA data. At setup time, Greentic resolves that data for the target bundle, tenant, team, and environment.

Why They Are Packs

Messaging and event integrations should be packs instead of loose components because the runtime behavior depends on more than code. The pack can carry components, flows, setup questions, i18n strings, static assets, and capability metadata together. That makes the integration installable, observable, controllable, and replaceable across deployments.

Publishing

Messaging and event extensions are signed .gtxpack artifacts published to a registry such as store.greentic.cloud. See Publishing Extensions for keys, signing, and distribution.