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

Participant

SMS · MMS · WhatsApp · chat

Conversation

One thread, shared historyCH · IM · MB · IS

Your app

REST + signed webhooks

Host: voiceml.voicetel.com Webhooks: HMAC-SHA256 signed Sandboxes: per-tenant Services

What Conversations gives you

One thread per participant, across every channel.

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.

Compatibility

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.

Endpoint map

ConversationsCRUD + create-with-participants Covered
MessagesCRUD · media · per-recipient receipts Covered
ParticipantsSMS · MMS · WhatsApp · chat bindings Covered
Webhooksper-conversation and account-wide, signed Covered
Roles, Users, Credentialsidentity · permissions · APNS / FCM keys Covered
Configurationdefaults · auto-routing per inbound address Covered
Servicesscoped sandboxes with their own users and roles Covered

FAQ

Questions about Conversations.

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.

Start your first conversation.

Open an account, swap your Twilio Conversations client to voiceml.voicetel.com, and send your first multi-channel thread the same hour. The official Twilio SDKs work as-is once the hostname and credentials are swapped.