Polymorfa vs WAHA

Three reasons teams move from WAHA

1. 01

   One request shape for both routes

   Polymorfa's Graph API accepts Meta's request shape for linked-device and Cloud API numbers. The number you address decides the route, and your code stays the same. Cloud API onboarding is in beta.^4,8

   WAHA: WAHA's payloads differ between its engines, and its engines page does not document a Cloud API engine.²

   # Meta's request shape, for a linked-device or a Cloud API number
   curl -X POST "https://api.polymorfa.com/graph/whatsapp/v26.0/$NUMBER_ID/messages" \
     -H "Authorization: Bearer $POLYMORFA_PROJECT_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "messaging_product": "whatsapp",
       "to": "15550001111",
       "type": "text",
       "text": { "body": "Your order shipped." }
     }'

2. 02

   No servers to size, and sends that are safe to repeat

   Polymorfa runs the sessions and stores their keys, and you pay only for days a number is online.³ A send with an Idempotency-Key that repeats within 24 hours returns 409 and does not send again.⁹

   WAHA: WAHA runs in your Docker host, so you size the servers, back up session storage and deploy each new release.^1,10 Its send guide does not document an idempotency key.¹¹

3. 03

   Calls from code and over SIP

   Polymorfa places and answers calls in a browser, in server code that reads and writes the audio, or on your PBX through a SIP trunk. Linked-device numbers also take video and group calls.^5,6

   WAHA: WAHA reports incoming calls as events and can reject them.¹²