The three Send* helpers in helpers/whatsapp.go construct their HTTP
requests directly instead of going through callAPI, and were missing the
Bearer token that the bridge's JWT middleware requires. Calls reached the
bridge as 401 Unauthorized.
In practice sendMessageHandler in mcp_tool.go bypasses SendMessage and
calls callAPI directly, so the text-send path happens to work; but the
file and audio-message MCP handlers route through SendFile and
SendAudioVoiceMessage respectively, so send_file and send_audio_message
were broken end-to-end.
Same shape as the recent DownloadMedia fix: fetch a JWT via
GetOrRefreshJwtToken and add Authorization: Bearer <token> on the
outgoing request.
DownloadMedia builds its HTTP request directly instead of going through
callAPI, and was missing the Bearer token that the bridge's JWT middleware
requires. As a result, every download_media MCP tool call returned 401.
Fetch a JWT via GetOrRefreshJwtToken (same path the rest of the helpers
use) and set the Authorization header on the request.
- Added ::int type casting to LIMIT and OFFSET parameters for PostgreSQL
- Fixed parameter numbering: changed placeholder(len(args)+2) to placeholder(len(args)+1) for OFFSET clause
- Resolves error: pq: could not determine data type of parameter (42P18)
This fix ensures proper parameter binding when using PostgreSQL with the
whatsapp-bridge ListChats endpoint, which is used by the MCP server
to retrieve WhatsApp chat lists.
Atul Singh