# Audit WhatsApp agents running on WATI

> Evidova reads the messages WATI posts as they happen, and scores the conversation they belong to.

## What it catches

WATI runs the inbox and moves the messages. It does not tell you whether the reply was right. Evidova reads both sides and scores the conversation against the checks you approved: whether the agent answered the question asked, whether it said it was not a person when asked, whether it promised a date nobody authorised, and where the customer stopped replying.

## Connect WATI

1. In Evidova, open Setup, choose WATI. Paste a secret only if something in front of WATI can add an x-wati-token header, because WATI publishes no signing scheme of its own.
2. Copy the URL we generate.
3. In WATI, add it as a webhook and switch on the received and sent message events.

```
https://app.evidova.com/ingest/webhooks/wati/<your-token>
```

> WATI does not sign what it sends, so the token in the path is what protects this URL. Treat it like a password: anyone who has it can post to your workspace. Rotate it from Setup if it leaks.

## What we read from WATI

| | |
|---|---|
| eventType | Which kind of message this is, and which way it went. WATI also posts the same field one level down inside data, and both shapes are read |
| owner | On the older message event, the only field that says which way it went. true is your side, false is the customer |
| waId | The customer's WhatsApp number. WATI writes it without a leading plus, so we add one, and it is what groups the conversation |
| bsuid | Used instead of waId when WATI sends no number at all |
| whatsappMessageId | Which message this is, and the id a repeated delivery is collapsed on. localMessageId, then id, are the fallbacks |
| created | When it happened, on an inbound message and on a template send |
| timestamp | When it happened, on a sessionMessageSent event |
| conversationId | WATI's own identity for the exchange, kept beside the number |
| text | What was said, in either direction |
| operatorEmail, operatorName | Who replied, when a person in the WATI dashboard did. Read the trap below |

## What we ignore, and why

WATI names the same message differently depending on the account and on how old the integration is, so nine event names are read: message, messageReceived and newContactMessageReceived on the way in, and sessionMessageSent and templateMessageSent on the way out, each of those last two also in its _v2 and _v2_bsuid form. Anything else produces no turns and its raw body is still kept. A template send is kept but marked as the platform's own outreach rather than your agent's reply, because approved copy sent on a schedule is not something the agent decided to say.

## One trap worth knowing

WATI does not say whether a reply came from your agent or from one of your people, so we work it out from one field. operatorEmail is filled in when somebody sent the message from the WATI dashboard, and empty when the message came in over the API. So a dashboard reply is credited to that person by email, and everything else is credited to the agent. A teammate who answers through tooling of your own will read as the agent and will be scored as one. Where people answer in the same conversations your agent does, keep them on the dashboard, or send those turns through the generic contract, which can mark a human turn outright.

## What WATI gives us

| | |
|---|---|
| Channel | chat |
| Audio | No |
| Timestamps | Seconds, on WATI's clock |
| Delivery | Webhook, push |
| Retries | WATI retries |

---

Source: https://evidova.com/platforms/wati