Platform services

Messaging

The Messaging service lets your services send and receive chat messages over WhatsApp, Telegram, and iMessage. Each provider exposes send functions other services can call, and forwards incoming messages to a webhook you choose.

What it does

Messaging is a two-way service. For outbound, it exposes named functions (like sendMessage) that the rest of your project calls via a FUNCTION_CALL event. For inbound, it acts as a relay: the provider delivers incoming messages to the service, which normalizes them and forwards them to a forwardUrl you configure (e.g. your app's /webhooks/<channel> endpoint).

Providers

  • WhatsApp — the Meta Cloud API. Send text and template messages; receive inbound messages.
  • Telegram — a bot. Send messages; the inbound webhook is registered automatically.
  • iMessage — a self-hosted relay (e.g. BlueBubbles). Send and receive over iMessage.

NestJS on Vercel

The Messaging service is a NestJS application deployed as a Vercel serverless function, following the same pattern as the other Dreambase integrations. Each provider handles its own Dreambase webhook (e.g. /whatsapp/webhook) and its own inbound route (e.g. /whatsapp/incoming).

Endpoints

POST/whatsapp/webhook
WhatsApp — challenge, deployment, health, metrics & function calls
POST/telegram/webhook
Telegram — challenge, deployment, health, metrics & function calls
POST/imessage/webhook
iMessage — challenge, deployment, health, metrics & function calls

Inbound forwarding

When a message arrives, the provider hits the service's inbound route and the service POSTs a normalized envelope to your forwardUrl:

{
  "channel": "whatsapp" | "telegram" | "imessage",
  "from": "<sender's channel-native address>",
  "text": "<message text, if any>",
  "messageId": "<provider message id, if any>",
  "timestamp": "<ISO timestamp, if any>",
  "raw": { /* the original provider payload */ }
}

The service publishes an incomingWebhookUrl output to register with each provider. It carries the forward target (and any verify / secret tokens) as query parameters, so the inbound handler is fully stateless.

Wire it into any service

Because Messaging is exposed as functions and forwards inbound to a URL, any service in your design can chat with users — a support bot, an alerting worker, a two-factor flow — without embedding channel credentials of its own.