WuKongIM Docs

Webhooks

Configure synchronous before-send admission and three asynchronous notifications.

Webhooks POST committed messages, offline-candidate recipients, and presence changes to one product endpoint. This is a server-outbound protocol, not a client inbox and not an inbound Product HTTP path.

Download the OpenAPI 3.1 Webhook contract

msg.before_send is independently enabled synchronous admission; its response allows, replaces, or rejects the send. Queue and retry semantics below apply only to the three asynchronous notifications. See Before-send business callback for configuration, requests, and failure policies.

Request

POST {http_addr}?event={event_name}
Content-Type: application/json

Existing query parameters are preserved and event is set or replaced. The event name exists only in the query. There is no common body envelope; each event has its own top-level JSON shape.

EventTop-level JSON
msg.before_sendone uncommitted message; synchronous send decision
msg.notifyarray of committed messages
msg.offlineflattened message object with offline UIDs
user.onlinestatusarray of compatibility status strings

Configuration

A non-empty webhook.http_addr enables asynchronous notifications. focus_events=[] delivers all three events.

[webhook]
http_addr = "https://events.example.com/wukongim"
focus_events = ["msg.notify", "msg.offline", "user.onlinestatus"]
queue_size = 1024
workers = 16
msg_notify_batch_max_items = 100
msg_notify_batch_max_wait = "500ms"
online_status_batch_max_items = 512
online_status_batch_max_wait = "2s"
offline_uid_batch_size = 512
request_timeout = "5s"
retry_max_attempts = 3

Asynchronous notifications are bounded and best effort

The current runtime uses node-memory queues with no disk outbox or crash replay. Receivers should durably enqueue and deduplicate before returning HTTP 200 promptly.

On this page