TL;DR: August 2026 is month-level news, not a dated changelog. Enable outgoing_calls_enabled, then POST /calls/outgoing for a 5-second default ring without audio. HTTP 200 means WhatsApp accepted the offer. Read catalogs, groups, LID lookups, and Partner proxy rotation after a ban as proof the gateway still tracks WhatsApp.
Throughout August 2026, Whapi.Cloud stayed current with WhatsApp. The month ships an outgoing call-as-attention ring without audio, and the remaining patches follow platform changes so business owners and integrators trust the API as a maintained business channel.
We've seen agency operators running a dozen client numbers on Node.js or n8n treat HTTP 200 as a finished conversation. The ring is the interrupt; the unread thread still needs the follow-up. This guide skips method-level setup and field-by-field webhook schemas.
What does an outgoing WhatsApp call without audio actually do?
Call-as-attention is a ring without audio or VoIP. You set a 0-30 second window, default 5, and a 200 only means WhatsApp accepted the offer.
HTTP 200 means WhatsApp accepted the offer, not that the recipient answered. No audio is transmitted, and the call ends when the duration window closes. That is the month's notable new capability, documented under initiate an outgoing WhatsApp call.
Community libraries could observe inbound calls for years and still needed WebRTC for an outbound ring. Whapi.Cloud now exposes the same job on HTTP: buzz the handset, then continue in chat.
Duration 0 ends immediately after the offer is acknowledged. The channel flag is outgoing_calls_enabled in Channel Settings; flipping it restarts the channel. Companion read is GET /calls/{CallID}, which returns result, answer time, and status already on the connected channel. It does not request call history from WhatsApp servers.
The request shape for POST /calls/outgoing is below. Pair the returned call_id with that GET for channel-local details.
// HTTP 200 here means WhatsApp accepted the offer.
// Treat it as answered and you skip the unread-chat follow-up while the ring is already gone.
const res = await fetch('https://gate.whapi.cloud/calls/outgoing', {
method: 'POST',
headers: {
Authorization: `Bearer ${process.env.WHAPI_TOKEN}`,
'Content-Type': 'application/json'
},
body: JSON.stringify({ to: '1234567890', duration: 5 })
});
const data = await res.json();
// data.status is initiated; pair call_id with GET /calls/{CallID} for channel-local details
Call events now include answered_at, finalized, and status. The payload map lives in incoming call webhooks.
Signaling rings nudge unread chats while Cloud Calling bills voice pulses
Use Cloud Calling when you already have permission for a real voice pulse. Use a gateway ring when chat sits unread and you need the handset to buzz, then follow up in WhatsApp.
Sixty-two percent of inbound business calls go unanswered (Aira, reported via SocialVik). Voicemail recovers roughly one in a hundred. Ring first, then follow up in WhatsApp when chat sits unread. Clinics already turn missed inbound voice into a booking thread.
In the official WhatsApp Business API, business-initiated calling needs explicit user permission, and four consecutive unanswered calls auto-revoke that permission. In Whapi.Cloud, POST /calls/outgoing is a signaling ring with no VoIP media, because the gateway runs on web-session sockets and does not sell IP-telephony. Reach for Cloud Calling as a cheap unread-chat nudge and you hit that permission ladder, then a revoke after four misses.
| Decision | Gateway call-as-attention | Meta Cloud Calling (BIC) |
|---|---|---|
| What the recipient gets | A short ring; the call ends after the duration window | A live WebRTC voice session |
| Permission model | Channel flag outgoing_calls_enabled |
Prior user permission; four unanswered calls revoke it |
| Success signal | HTTP 200 = WhatsApp accepted the offer | An actual connected voice pulse on the Cloud Calling product |
| Job it completes | Nudge an unread WhatsApp thread | Hold a real phone conversation |
Agencies already associate proactive outreach to new contacts with 15-30% ban rates versus under 2% for inbound-only bots. Keep the new outbound ring as a follow-up to an unread thread. WhatsApp's server-side spam detection is what reacts; Whapi.Cloud production plans do not cap call frequency.
Catalog, orders, groups, communities, polls, and labels received August maintenance
Treat shop, group, and identity patches as one currency proof that the HTTP surface still moves with WhatsApp.
Incoming webhooks now arrive with @lid identities; LID-to-phone lookups restore the CRM routing key. Projects that skip the lookup start storing duplicate CRM rows the week WhatsApp switches the webhook identity. Sends fail when the chat table has no LID mapping after that migration. The conceptual repair path is how WhatsApp LID maps back to a phone number.
Shop ops: catalogs, products, and orders
Catalog listing endpoints now fail unless the instance is authorized, and WhatsApp rate-limits catalog GraphQL. August maintenance put create, update, and delete back under a live session, including contact catalogs, product-message send, and order retrieval by OrderID or order_token. LID orders that stall retry via the phone mapping. A public catalog scrape with no connected channel is what broke.
Groups, Communities, and polls
Group icon updates, simultaneous poll voting, and adding participants after a Community is created were the messy edges. Community retrieval after channel startup failed while the session was up and the Community list was still empty. WhatsApp 479 on a group send now retries.
Partial group creation returns unprocessed_participants instead of pretending every add succeeded. Chat history sync, status deletion, and text status font_type sit in the same bucket: the gateway tracked what WhatsApp changed.
LID lookups, labels, and phone-check accounting
LID identifiers replaced phone JIDs on a growing share of inbound events. Lookups restore CRM routing keys. GET /contacts/ids/{ContactLID} (getIdByLid) is the lookup that restores the phone CRM key. LID-to-phone returns 404 when there is no mapping and 502 when the lookup service is unavailable. Those two codes are the difference between "this person is unknown" and "the lookup path is down."
Label sync from the phone and label management on LID chats landed in the same pass. Trial and Sandbox LID-to-phone lookups count toward the phone-check limit, so a mapping loop in a test channel burns the same quota as a production existence check. Quoted message validation now returns 400 instead of 500. Number verification is cached and batched.
Change the proxy before you authorize a replacement number
After a ban, change the proxy before authorizing a replacement number. The same compromised IP is how replacement SIMs get banned in sequence.
In practice, teams that reconnect a new SIM on the same proxy watch the replacement fail the same week. An agency we worked through this with replaced a banned SIM, kept the old proxy, and lost the new number before warmup finished. Change the proxy before you authorize a replacement number. The Partner API now exposes the missing step: change the channel proxy on the fleet, then authorize the next number. Regional and default proxy choices are documented under default and regional proxies.
Warmup, volume spikes, and identical bulk copy still belong in how to avoid a WhatsApp ban in 2026. This month's story is reconnect order after a ban. Unique proxies and regional providers already isolate channels; Partner API rotation is the lever when a number is already gone. Over 3,000 active clients run this stack in production daily.
Stale WhatsApp versions trigger handshake 405 until the gateway tracks
Stale WhatsApp versions trigger handshake 405 until the gateway tracks the live protocol. That is the month's quiet reliability story.
Self-hosted stacks pin a protocol version, WhatsApp enforces a newer handshake, and sockets fail with 405 even when the client advertises a current web version. Whapi.Cloud absorbs those protocol shifts upstream, so customer HTTP paths stay stable while the gateway tracks WhatsApp. If a channel still returns 405 after a platform cut, use the chat widget on whapi.cloud.
What should operators take from the August 2026 digest?
Throughout August 2026, Whapi.Cloud shipped a call-as-attention ring and patched the rest so operators trust a maintained WhatsApp channel.
The outgoing ring without audio is the visible ship. Catalog, groups, LID lookups, labels, and Partner proxy rotation are the maintenance that keeps the channel current. Dated release notes live on the product changelog. A 200 still only records that WhatsApp accepted the offer.
Whapi.Cloud connects through web-session sockets, the same path WhatsApp Web uses. In that unofficial API category, signaling rings nudge; Cloud Calling bills WebRTC voice pulses.
