Presence Updated
Triggered when a contact starts typing, recording audio, or changes their online status.
Best practices
Use 'composing' (typing) status to show live indicators in your dashboard.
Don't rely on this for uptime monitoring as it only shows activity for specific chats.
The Digital Pulse: Mastering Presence and Activity Webhooks
In the architecture of a high-performance messaging system, text is only half of the conversation. The other half is Presence—the subtle, high-frequency signals that indicate when a human is looking at their screen, composing a thought, or recording a voice note. The [presence.update] webhook is the "Social Sensor" of the Wawp platform. It provides your infrastructure with real-time insight into the intentions of your contacts before they ever press the "Send" button.
This guide provides an architectural deep-dive into the strategic value of presence monitoring, moving beyond "Activity Tracking" into the realm of Social Intelligence and Conversational Flow Management.
🏗️ Architectural Philosophy: The Social Contract of Availability
To master the Presence API, one must recognize the psychological weight of the "Typing..." indicator. It represents active focus. Within Wawp, presence is usually scoped to an Individual JID (@c.us) within a specific chat context.
1. The Hierarchy of Activity
The presence event captures the progression of human-device interaction:
- Composing (Typing): The user is actively entering text into the input field. This is the strongest signal of "Pending Input."
- Recording: The user is holding the microphone button to record a voice note. This provides a "Media Warning"—your system should expect an audio payload shortly.
- Paused: The user has stopped typing but still has the chat window open. This is a state of "Deliberation" or "Interruption."
- Available / Unavailable: The global "Online" or "Last Seen" status. (Note: These are only available if the user's privacy settings allow it).
2. The Relationship Between Presence and Priority
A presence event is a Temporary State Mutation. Unlike a message, which is a permanent record, presence is a fleeting signal. Your architecture should treat these events as "Volatile Data." They are primarily used to update a Live UI or to pause bot logic, rather than being archived in a long-term data warehouse.
🚀 Strategic Use Cases: Powering Socially Intelligent Bots
Presence and activity signals transform a static bot into a "Conversational Orchestrator" that respects human rhythms.
1. The "Respectful AI" Bot (Collision Avoidance)
One of the most frustrating user experiences is when a bot sends a long answer while the user is still typing their next question.
The Strategic Workflow: When your bot generates a response, it first checks the current "Activity State" of the [chatId]. If a [presence.update] event of type composing has arrived in the last 10 seconds, the bot pauses its output. It waits for the user to finish typing and send their message before delivering its own answer. This creates a "Natural Turn-Taking" flow that mimics human conversation.
2. Real-Time Dashboard Synchronicity
For human-led support teams, the presence webhook is the engine of the "Agent Awareness" feature. When an agent sees "Customer is typing..." on their dashboard, they know to wait rather than asking "Are you there?". This simple visual cue reduces redundant messages, lowers agent fatigue, and gives the customer the space they need to compose complex queries.
3. Presence as a "Sentiment Warm-up"
Track the "Time-to-Reply" starting from the first composing event rather than the final message timestamp. A user who types for 3 minutes for a 2-word message is likely frustrated or struggling with your interface. Your system can detect this prolonged "Composing State" and proactively suggest human assistance before the user even finishes their message.
🛡️ Administrative Mandate: Balancing Intelligence and Privacy
1. The "Subscribed vs. Unsubscribed" State
Presence updates on WhatsApp are typically Contextual. You receive typing indicators for users you are currently interacting with. For global "Online" status, you may need to call the /presence/subscribe endpoint.
The Strategic Rule: Only subscribe to presence for "Active Leads" or "High-Priority Support Tickets." Maintaining 10,000 active presence subscriptions simultaneously is an architectural anti-pattern that can lead to backend throttling and unnecessary bandwidth costs.
2. Respecting the "Invisible" User
Privacy is a core pillar of the WhatsApp ecosystem. If a user has disabled "Read Receipts" or "Online Status," your system will not receive these webhooks. A premium architecture must fail gracefully. If presence data is missing, your system should default to "Passive Mode"—treating every message as if it were sent without warning. Never attempt to "Infer" presence via invasive polling, as this can lead to account flags or user complaints.
🛡️ Operational Best Practices: Handling the High-Frequency Signal
- The "Debounce" Strategy: Presence updates can fire every few seconds. Do not trigger a database write for every "User is typing" packet. Instead, use an In-Memory Cache (like Redis) to store the "Current State" of a chat. Only push an update to your frontend UI if the state actually changes (e.g., from
pausedtocomposing). - Visual State Lifespan: Typing indicators should have a "Time-to-Live" (TTL) on your dashboard. If you don't receive a fresh [
presence.update] within 15 seconds, your UI should automatically hide the "Typing..." indicator. This prevents a "Stuck UI" if a user closes their app without thepausedevent firing correctly. - Presence in Groups (@g.us): In a group context, you will receive presence updates for multiple different [
from] JIDs simultaneously. Your system must correctly map these activities to the specific user's avatar within the group UI, allowing agents to see exactly which participant is currently responding.
⚙️ Engineering Best Practices: The Validation Loop
- Low-Latency Ingestion: Unlike a message, a presence signal loses 90% of its value if it is delayed by more than 2 seconds. Ensure your presence webhook handler is hosted on a high-availability, low-latency node.
- Verify Event Ordering: Use the [
timestamp] in the event metadata to ensure you aren't processing an old "Typing" packet after a newer "Paused" packet. - Coordinate with "Start Typing": If your bot is about to reply, call the
/v2/send/start-typingendpoint yourself. This closes the "Symmetry Loop"—the user sees that the bot is "Thinking," and the bot sees that the user is "Waiting."
🎯 Conclusion: Beyond Text—The Reactive Pulse of Engagement
The Presence Update Webhook is the "Peripheral Vision" of your WhatsApp integration. By building an architecture that listens to these subtle, high-frequency signals, you move your business from "Reading Logs" to Understanding Human Momentum. You build systems that respect silence, wait for input, and provide reassurance through live visual feedback. In the world of Wawp, presence is the signal that turns a cold interaction into a living, breathing conversation.
Expected Responses
Explore all possible responses and outcomes from the server. We have documented each status code with data examples to make success and error handling easier.
Example
{
"id": "evt_01...",
"timestamp": 1634567890123,
"session": "default",
"metadata": {
"user.id": "123",
"user.email": "email@example.com"
},
"engine": "WEBJS",
"event": "presence.update",
"payload": {
"chatId": "11111111111@c.us",
"type": "composing",
"from": "11111111111@c.us"
},
"me": {
"id": "11111111111@c.us",
"lid": "123@lid",
"pushName": "Instance"
}
}Command Palette
Search for a command to run...