# Audit SMS and WhatsApp agents running on Twilio

> Evidova reads the messages Twilio already posts to your webhook, and scores the conversation they belong to.

## What it catches

Twilio moves the messages. It does not read them. Evidova reads both sides of the conversation and scores it 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 something nobody authorised, and where the customer stopped replying.

## Connect Twilio

1. In Evidova, open Setup, choose Twilio, and paste your auth token. Add your Account SID as well, for the reason under the trap below.
2. Copy the URL we generate.
3. In the Twilio console, set it, exactly as given, as the webhook on your number for incoming messages and for status callbacks.

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

> The token in the path names your workspace, and the secret proves the request is Twilio's. A request that fails that proof is refused with a 401 and recorded, not dropped quietly.

## What we read from Twilio

| | |
|---|---|
| MessageSid | The message's identity. Required. An older webhook that sends SmsSid instead is read the same way |
| From | The customer's number, written as E.164. It is what groups the conversation. A whatsapp: prefix is taken off, so SMS and WhatsApp with one number stay one conversation |
| To | Who the agent replied to, which is what groups an outbound message |
| Body | What was said, in either direction |
| NumMedia, MediaUrl0 and its content type | The first audio attachment, for the audio checks |
| MessageStatus | Which kind of delivery this is. received, or nothing at all, is the customer. sent is your agent |

## What we ignore, and why

Twilio posts a callback at every step of one outbound message: queued, sent, delivered, read, failed. We read sent and nothing else, because they all repeat the same MessageSid and one message has to be one turn.

## One trap worth knowing

A Twilio webhook carries no time at all. Nothing in the form says when the message was created, so the message lands with its time unresolved and we read date_created back from Twilio's own record of it. That read needs your Account SID. Without it, or when Twilio refuses the read for a reason repeating it cannot cure, the message is kept with its time openly unresolved instead of costing you the delivery, and the gap is written to the log. So set the Account SID: it is what puts these messages on the clock.

## What Twilio gives us

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

---

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