Integrations

By enabling customers to connect Polser with their tools, such as CRM systems, payment platforms, and calendar applications, we are streamlining workflows.

In addition to our mandatory native integration with WhatsApp for using Polser, we also enable you to connect workflow tools through our Webhook technology, as well as integrations with Zapier and Microsoft's Power Automate. This allows you to leverage the workflow tools you are already using and are familiar with.

If you configure any integration, Polser will send any incoming and outgoing event from Meta to the URLs provided on each integration settings page.

Zapier URL configuration

These are standard events from Meta. You can see the payload you can except depending on the event triggered in the official Meta documentation. Polser will add additional user information to the event where available so that you can leverage those additional datapoints in your third party integration platforms.

Webhook event payload

When an integration is configured, Polser sends an HTTP POST to your webhook URL. The body always looks like this:

{
  "event": { /* WhatsApp Cloud API webhook payload from Meta */ }
}

These are standard Meta events. You can review the full structure in the official Meta documentation. Polser adds one field on each entry:

Field	Values	Meaning
entry[].direction	incoming or outgoing	incoming = message written by the contact outgoing = message sent by your business (agent or API).

Where available, Polser may also attach extra contact data under entry[].changes[].value.extendedProfile.

How to identify the contact

Read identity from the Meta payload inside event:

Scenario	Fields to use
Contact has a visible phone number	contacts[0].wa_id and messages[0].from
Contact has a WhatsApp username	contacts[0].profile.username and/or contacts[0].username
Business-scoped user id (BSUID)	contacts[0].user_id and/or messages[0].from_user_id

A single event can include phone, username, and BSUID together. Prefer the phone number when present; otherwise use the BSUID or username.

Do not infer direction from profile.name. Display names can contain @ (for example JennZ@b) and that is unrelated to whether the message is incoming or outgoing.

Example: incoming message with phone number

{
  "event": {
    "object": "whatsapp_business_account",
    "entry": [
      {
        "id": "123456789012345",
        "direction": "incoming",
        "changes": [
          {
            "field": "messages",
            "value": {
              "messaging_product": "whatsapp",
              "metadata": {
                "display_phone_number": "34123456789",
                "phone_number_id": "1000000000000001"
              },
              "contacts": [
                {
                  "profile": {
                    "name": "Alex@Work"
                  },
                  "wa_id": "34987654321",
                  "user_id": "ES.0000000000000001"
                }
              ],
              "messages": [
                {
                  "from": "34987654321",
                  "from_user_id": "ES.0000000000000001",
                  "id": "wamid.SAMPLE_MESSAGE_ID_PHONE_001",
                  "timestamp": "1710000000",
                  "type": "text",
                  "text": {
                    "body": "Hi, I need more information."
                  }
                }
              ]
            }
          }
        ]
      }
    ]
  }
}

Example: incoming message with WhatsApp username (no phone number)

If a contact hides their phone number, Meta may omit wa_id and messages[0].from. Use username and user_id / from_user_id instead:

{
  "event": {
    "object": "whatsapp_business_account",
    "entry": [
      {
        "id": "123456789012345",
        "direction": "incoming",
        "changes": [
          {
            "field": "messages",
            "value": {
              "messaging_product": "whatsapp",
              "metadata": {
                "display_phone_number": "34123456789",
                "phone_number_id": "1000000000000001"
              },
              "contacts": [
                {
                  "profile": {
                    "name": "Sample User",
                    "username": "sample.user"
                  },
                  "user_id": "NP.0000000000000002"
                }
              ],
              "messages": [
                {
                  "from_user_id": "NP.0000000000000002",
                  "id": "wamid.SAMPLE_MESSAGE_ID_USERNAME_001",
                  "timestamp": "1710003600",
                  "type": "text",
                  "text": {
                    "body": "Hello! I would like to receive more information."
                  }
                }
              ]
            }
          }
        ]
      }
    ]
  }
}

Recommended handling in your CRM or automation

1. Check entry[0].direction === "incoming" before creating or syncing a contact from a customer message.

2. Resolve the contact in this order: phone (from / wa_id) → BSUID (user_id / from_user_id) → username.

3. Store the BSUID when present so you can keep matching the contact if the phone number later becomes unavailable.

4. Treat profile.name as a display name only.

Button taps

When a contact taps a button, Polser sends the tap to your webhook URL as an incoming message, like any other message from the contact. Taps arrive in the same format for both kinds of buttons: quick-reply buttons in a template message and reply buttons in a free-form message with reply buttons. You can handle both with the same code.

Field	Meaning
messages[0].type	button
messages[0].button.payload	Your identifier: the payload you set with button_payloads in a template message, or the id you set on the button in a free-form message with reply buttons
messages[0].button.text	The button label the contact saw

Example: contact taps a button

"messages": [
  {
    "from": "34987654321",
    "id": "wamid.SAMPLE_MESSAGE_ID_BUTTON_001",
    "timestamp": "1710007200",
    "type": "button",
    "button": {
      "payload": "see_prices",
      "text": "See prices"
    }
  }
]

The example shows only the messages array. The rest of the event has the same structure as the examples above.

Embedded conversation

Polser provides a way for customers to embed a single conversation view into their third-party tools, such as their CRM. The conversation view can be loaded by providing a direct URL to the contact's phone number, following this format:

https://your-polser-account.polser.app/conversation/contact-phone-number

For example, https://demo.polser.app/conversation/447822001881.

The embedded conversation view will appear as follows:

In CRM integrations where an open conversation involves a contact with no chat history or record, Polser will not have a name or surname for that user, which only appear when a new chat begins. In this scenario, the UI will display their phone number instead of a username.

To prevent this UI issue, we offer a specific URL structure that utilizes parameters to replace the UI name and surname placeholders:

https://your-polser-account.polser.app/conversation#phone=3466666666&firstName=Jane&lastName=Doe

For example, https://demo.polser.app/conversation#phone=3466666666&firstName=John&lastName=Doe

As shown in the image above, the name is inserted via URL parameters when opening this window. Please note there is also an icon that lets you start a new chat with this person.

---

Integrations are available through the web application within Polser.