diff --git a/api-reference/server/services/transport/whatsapp.mdx b/api-reference/server/services/transport/whatsapp.mdx
index ec4fd557..a0a4e9ce 100644
--- a/api-reference/server/services/transport/whatsapp.mdx
+++ b/api-reference/server/services/transport/whatsapp.mdx
@@ -113,6 +113,35 @@ WhatsAppTransport requires a webhook server to handle incoming calls and a bot i
 
 The `WhatsAppClient` handles the WhatsApp-specific webhook processing and call management, while the actual audio transport uses a `SmallWebRTCConnection` for each call.
 
+### Connection Callback Signature
+
+When handling webhook requests, you provide a connection callback that receives the established WebRTC connection and call metadata:
+
+```python
+async def connection_callback(
+    connection: SmallWebRTCConnection,
+    call: WhatsAppConnectCall
+):
+    # Access caller information
+    caller_number = call.From  # Caller's phone number
+    call_id = call.id
+    direction = call.direction  # "inbound" or "outbound"
+    
+    # Spawn your bot with the connection
+    await spawn_bot(connection, call)
+```
+
+The `WhatsAppConnectCall` object contains:
+- `From`: Caller's phone number
+- `To`: Called phone number
+- `id`: Unique call identifier
+- `direction`: Call direction ("inbound" or "outbound")
+- `timestamp`: Call timestamp
+
+<Warning>
+The single-argument `connection_callback(connection)` signature is deprecated as of Pipecat 1.4.0. Update your callbacks to accept both `connection` and `call` arguments to receive caller metadata. The old signature still works but emits a `DeprecationWarning`.
+</Warning>
+
 See the [complete example](https://github.com/pipecat-ai/pipecat-examples/tree/main/whatsapp) for a full implementation including:
 
 - FastAPI webhook server with verification endpoint
diff --git a/api-reference/server/utilities/runner/guide.mdx b/api-reference/server/utilities/runner/guide.mdx
index db3c55ba..b0cc81d2 100644
--- a/api-reference/server/utilities/runner/guide.mdx
+++ b/api-reference/server/utilities/runner/guide.mdx
@@ -160,7 +160,7 @@ python bot.py -t daily   # Restrict to Daily → DailyRunnerArguments
 Runner arguments are how the runner communicates transport-specific information to your bot. The runner determines which transport to use based on the command-line arguments, then creates the appropriate runner arguments:
 
 - **`DailyRunnerArguments`**: Contains `room_url`, `token` (Optional), `body` (Optional) for joining Daily rooms
-- **`SmallWebRTCRunnerArguments`**: Contains `webrtc_connection` for local WebRTC sessions
+- **`SmallWebRTCRunnerArguments`**: Contains `webrtc_connection` for local WebRTC sessions, `body` (Optional) for WhatsApp call metadata
 - **`WebSocketRunnerArguments`**: Contains `websocket` for both telephony and plain WebSocket connections. The `transport_type` field distinguishes them — `"websocket"` for plain (non-telephony) clients connecting via `/ws-client`, or a telephony provider value for connections via `/ws`.
 
 All runner arguments also include:
@@ -168,6 +168,10 @@ All runner arguments also include:
 - **`handle_sigint`**: Whether the bot should handle SIGINT (Ctrl+C) signals (managed automatically)
 - **`handle_sigterm`**: Whether the bot should handle SIGTERM signals (managed automatically)
 
+<Note>
+For WhatsApp connections, `SmallWebRTCRunnerArguments.body` contains a `WhatsAppConnectCall` object with caller metadata (phone number, call ID, direction, timestamp). This allows your bot to access caller information without additional API calls.
+</Note>
+
 <Warning>
   `handle_sigint` and `handle_sigterm` are development only features and cannot
   be used when deploying to Pipecat Cloud.
@@ -651,6 +655,26 @@ ngrok http 7860
   to restrict the runner to Daily.
 </Note>
 
+## Error Handling and Debugging
+
+The development runner includes built-in error handling to help debug issues with incoming requests and webhook payloads.
+
+### 422 Validation Error Logging
+
+When FastAPI receives a malformed request that fails Pydantic validation (HTTP 422 Unprocessable Entity), the runner automatically logs both the validation errors and the raw request body. This makes it much easier to debug malformed payloads from any transport — WhatsApp webhooks, WebRTC signaling, telephony providers, or RTVI clients.
+
+The runner logs:
+- The request URL path where the error occurred
+- Detailed validation error messages from Pydantic
+- The raw request body (up to 5000 characters)
+
+```
+ERROR: 422 Validation error on /whatsapp: [{'type': 'missing', 'loc': ['body', 'calls'], ...}]
+ERROR: Raw body: {"from": "+1234567890", "to": ...}
+```
+
+This automatic logging applies to all runner endpoints and helps identify issues with webhook configurations, client implementations, or API changes without requiring manual debugging code.
+
 ## Quick Reference
 
 All transports are available from `python bot.py`; the `-t` form below restricts the server to one. Access columns assume the default `localhost:7860`.