Added
- Integration Fabric: provision and connect external services to WhatsApp sessions. ADMIN operators can mint per-plugin instances — one per external account — through a provisioning API and a new dashboard Instances tab, each with its own HMAC-verified inbound webhook endpoint, operator-set secret, and per-session configuration. Integration plugins gain the capabilities needed to build a two-way bridge:
ctx.registerWebhookto receive that inbound traffic,ctx.mappingsto correlate a WhatsApp chat with an external conversation, a session-and-chat-scoped handover gate so a chat handed to a human is withheld from the owning plugin while the bot and other plugins still receive it, andnet.allowConfigHoststo permit an outbound request to a host drawn from the instance's own configuration. This is the foundation for provider adapters. (#568, #570, #571, #575, #585, #587, #588, #589)
Fixed
- Replying to and forwarding to a LID-migrated contact no longer fail with HTTP 500 on the whatsapp-web.js engine. These paths sent to the phone id (
@c.us) like the original send bug (#573), so a contact WhatsApp had migrated to@lidrejected them withNo LID for user. They now resolve the recipient the same way as a normal send (including the self-heal retry), and a forward reads back its delivered id from the resolved chat so delivery status still reconciles. (#583) - The typing/presence endpoint no longer returns HTTP 500 on the Baileys engine when a presence update fails. Presence is best-effort; a failure (e.g.
No LID for userfor a migrated contact) is now caught and logged atWARNand the request succeeds, matching the whatsapp-web.js engine. This also covers the presence agent tool. (#583) - Chat history for a LID-migrated contact is no longer split across two entries on the whatsapp-web.js engine. The engine now records the
phone ↔ lidmapping it learns (when resolving a send, and when resolving an inbound@lidsender's number), so the messages API bridges a contact's@c.usand@lidrows into one conversation — previously only the Baileys engine populated this mapping. (#583) - The dashboard chat list no longer refetches on every message sent to a LID-migrated contact. The outgoing echo can arrive addressed as
@lidwhile the open chat is@c.us; the sent message is already shown via the send response, so the sidebar no longer triggers a full reload for an outgoing echo with no matching chat. (#583)