Feature Request: First-class outbound message API for proactive and async delivery

[yidianyiko]

Summary

ClawScale currently works well for the synchronous flow:

inbound message -> backend reply -> immediate send back

However, many production agent systems also need a first-class outbound delivery path that is not tied to a live inbound request.

Examples:

• reminders
• delayed follow-ups
• proactive notifications
• workflow-triggered outbound messages
• operator-initiated sends
• retries for previously failed sends

Problem

Today, ClawScale appears optimized for request/response chat routing. This makes it difficult to use as the gateway layer for external runtimes that already own their own async job system and need to send messages later, independently of inbound traffic.

Without a standalone outbound API, integrators are forced to:

• treat ClawScale as only a synchronous chatbot gateway
• build custom patches/forks
• or bypass ClawScale entirely for proactive sends

Proposed solution

Add a first-class outbound delivery API and internal delivery model.

Possible endpoints:

• POST /api/messages/send
• POST /api/messages/batch-send
• GET /api/messages/:id

Suggested request fields:

• channelId
• endUserId or platform-native destination
• conversationId or external conversation reference
• content
• contentType
• metadata
• idempotencyKey
• optional scheduleAt
• optional replyToMessageId
• optional threadId
• optional accountId

Suggested delivery states:

• queued
• sent
• failed

Expected behavior

• Send messages without requiring a preceding inbound request
• Support async delivery status
• Support retries and idempotency
• Preserve channel-specific metadata needed for delivery
• Work consistently across WhatsApp / WeChat / other adapters

Why this matters

This would make ClawScale much more useful as a true IM gateway for external agent runtimes, not only as a synchronous "reply forwarder".

Acceptance criteria

• A documented outbound API exists
• A message can be sent proactively to an existing user/channel without a live inbound event
• Delivery status can be observed programmatically
• Duplicate requests can be prevented with idempotency
• At least one existing adapter demonstrates this flow end-to-end