Audit chat agents on Zendesk Sunshine Conversations

Evidova reads the messages Zendesk sends as they land, and scores the conversation they belong to.

What it catches

Sunshine Conversations carries one conversation across every channel you have connected to it. It does not tell you whether the reply was right. Evidova reads both sides 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.
Where the customer stopped replying.

Connect Zendesk

In Evidova, open Setup, choose Zendesk, and save the connector so that it has a URL.
Copy the URL we generate.
Sunshine Conversations has no screen for this, and no way to ask it what has changed since last time, so the webhook is the only way in. Create it through the Sunshine API instead: POST to /v2/apps/{appId}/integrations/{integrationId}/webhooks with that URL as the target and conversation:message as the only trigger.
The response carries a secret. Paste it back into the Evidova connector. Reading the same webhook again shows it a second time if you lose it.

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

Zendesk 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 Zendesk

events[].type	Which trigger fired. Only conversation:message is read
events[].payload.conversation.id	The conversation. It is what groups the messages, and there is no phone number or email in play
events[].payload.message.id	Which message this is. Required
events[].payload.message.received	When Zendesk received it, to the millisecond
events[].payload.message.content.type	What shape the message is. text, image and file are read, and nothing else is
events[].payload.message.content.text	What was said, which on an image or a file is whatever words came with it
events[].payload.message.author.type	Which side sent it. business is your side, anything else is the customer
events[].payload.message.author.subtypes[]	Whether a person, the platform or your AI agent sent it. Zendesk's own agent subtype is a person in its agent workspace, activity is the platform's own notice, and a business send with no marker at all is read as your AI agent
events[].payload.message.author.userId, .displayName	Who replied, when Zendesk marked the author as a person. A name with no id is kept on its own, because it is what the customer saw

What we ignore, and why

One delivery can carry several entries at once, belonging to different customers and different conversations. Each entry is read on its own, so a bad entry costs only itself.

An entry that is not a conversation:message is left out, because that is the only trigger this connector asks Zendesk for.

A message whose content type is not text, image or file produces no turn either. Those three are the shapes we can take words out of, and inventing words for the rest would put sentences in somebody's mouth.

One trap worth knowing

Zendesk does not sign these deliveries. The secret it shows you when the webhook is created is the same secret it sends back, unchanged, in the X-Api-Key header.

So what reaches us is a shared password, not a signature over the body. Anyone holding both the URL and that secret can post whatever they like. Treat the pair as a password, and create a new webhook to change it.

Nothing ties the secret to the bytes either, so a captured delivery can be sent at us again. What stops it becoming a second turn is the message id, not the secret.

What Zendesk gives us

Channel	chat
Audio	No
Timestamps	Milliseconds, on Zendesk's clock
Delivery	Webhook, push
Retries	Zendesk retries