Voice notes + faster inbound media downloads

Released: June 10, 2026

Public API — voice notes Added

Outbound audio messages now accept an audio.voice boolean. When true, WhatsApp renders the bubble as a voice note (waveform + play icon + microphone glyph) on the recipient’s phone instead of a generic audio file attachment. Voice-note presentation is also a prerequisite for the recipient-side speech-to-text transcript feature.

{
  "messaging_product": "whatsapp",
  "to": "+628123456789",
  "type": "audio",
  "audio": {
    "link": "https://cdn.example.com/order-ready.ogg",
    "voice": true
  }
}

The field is optional; omitting it (or setting false) keeps the existing audio-attachment behaviour, so nothing changes for senders who don’t opt in. See the updated Send audio guide for the full payload and notes on which file formats encode well as voice notes.

This mirrors the Meta WhatsApp Cloud API change shipped on October 16, 2025 and forwards the flag verbatim — no translation layer.

TypeScript SDK Added

@kirimdev/sdk accepts the new voice field on audio payloads automatically — the SDK derives its types from the same OpenAPI spec that powers the API reference. No new SDK method is required; the field appears as an optional boolean on the existing type: 'audio' variant of phone.messages.send(...).

MCP server Added

The existing send_message MCP tool now accepts audio.voice — Claude, ChatGPT, and other MCP-aware clients can compose voice notes immediately. No new tool registration is needed.

Inbound media — faster downloads Changed

Media downloads for inbound image / video / audio / document / sticker messages now use the signed CDN URL Meta inlines on the webhook payload (a change Meta rolled out on October 16, 2025). This removes one Graph API round-trip per inbound media — in practice inbound photos / voice notes / documents arrive in your S3 bucket roughly twice as fast, and a class of GET /{mediaId} rate-limit errors goes away entirely.

The fallback path remains: if the inline URL is missing (older webhooks, message-history backfill) or expired (rate-limit pause delayed the job past the ~5-minute TTL), the worker still issues GET /{mediaId} and retries the download. No customer-side action is required; URLs in messages[].media_url keep the same shape.

Read the send-audio guide

API Reference