Conversations

Multi-channel chat sessions on one Twilio-compatible API.

VoiceTel Conversations gives application teams a single REST surface for SMS, MMS, WhatsApp, and in-app chat — same participant, same thread, same history — without re-implementing channel-specific glue for every project.

Conversations API reference Sign up

What Conversations gives you

  • Threaded multi-channel chat

    One conversation resource collects every message a participant sends — SMS, MMS, WhatsApp, or in-app — so application state stays consistent regardless of which channel a user replies on.

  • Participants, roles, and users

    Add participants by phone number, WhatsApp ID, or chat user. Per-conversation roles assign permissions; reusable users carry identity across conversations.

  • Signed webhook events

    Per-conversation or account-wide webhook subscriptions deliver message, participant, and read-receipt events to your endpoint. Same HMAC-SHA256 signature scheme as voice callbacks.

  • Service sandboxes

    Need to isolate workloads — staging from production, customer A from customer B? Conversations Services scope an entire chat environment under one parent service resource.

Twilio-compatible by design

The Conversations endpoints mirror the Twilio v1 surface — same paths, same field names, same SID prefixes (CH for conversations, IM for messages, MB for participants, IS for services). Twilio's official client libraries work against voiceml.voicetel.com with a hostname + credential swap.

For a side-by-side endpoint map, see the VoiceML compatibility matrix.

What's covered

  • Conversations — CRUD + single-call create-with-participants.
  • Messages — CRUD, media attachments, per-recipient receipts.
  • Participants — SMS, MMS, WhatsApp, and chat bindings; reverse-lookup index by participant address.
  • Webhooks — per-conversation and account-wide event subscriptions, signed.
  • Roles, Users, Credentials — identity, permissions, and push-notification keys (APNS / FCM).
  • Configuration — defaults, auto-routing rules per inbound address, account-wide webhooks.
  • Services — scoped sandboxes with their own users, roles, conversations, and configuration.

Conversations FAQ

Do my existing Twilio Conversations SDK clients work against VoiceTel?

Yes — the v1 surface mirrors Twilio's. Point the client at voiceml.voicetel.com and use your VoiceTel account credentials. Paths, field names, and SID prefixes match.

Which channels does VoiceTel Conversations support?

SMS and MMS today via the same providers as VoiceTel Messaging. WhatsApp and in-app chat bindings follow the Twilio participant model; channel availability depends on which provider integrations are enabled on your account — contact support to confirm coverage for your use case.

How do Conversations and Messaging differ?

Messaging is the per-message API — send one SMS, get a delivery receipt. Conversations is the per-thread API — group every message a participant sends across channels into one resource, with shared history and participant state. Use Messaging for transactional fan-out; use Conversations when you need stateful multi-turn application chat.

Are Conversations webhooks signed the same way as voice webhooks?

Yes. HMAC-SHA256 over the canonicalised request body and URL, signed with your account auth token. See the webhook signatures guide.

Can I run staging and production traffic in the same account?

Yes — create separate Conversations Services. Each service is a sandbox with its own users, roles, conversations, configuration, and webhooks under one parent account.