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

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.
Copy the URL we generate.
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