How to read the API Log Report when an integration stops working

An integration that worked yesterday and fails today is one of the more frustrating things to debug, because the failure is usually silent. A lead stops loading, a screen pop stops firing, and nobody gets an error. The API Log Report is where you go to find out what your system actually received and how it answered.

It displays the API log entries for a date and time range, and you can narrow the results by API User, Agent User, Function, and Result. Those four filters are the whole skill of reading it.

The four filters and what they mean

• API User — the account a server-to-server caller used, the Non-agent API credential a CRM or dialer-control script logs in with. Filter here when a back-office integration breaks.
• Agent User — the agent tied to an Agent API call, the kind the agent screen makes on a person's behalf. Filter here when one agent's screen actions stop working.
• Function — which API (application programming interface) function was called, like adding a lead or changing a status. This tells you which integration is involved without reading every line.
• Result — what the system returned. This is the column that tells you whether the request succeeded or was rejected, and why.

A read order that finds the break fast

Don't read the whole log — filter your way to the failure. Start with the time range when the integration last worked and first failed, then narrow by Function, then by Result. If the failing requests aren't even in the log, the problem is upstream: the caller never reached you.

Decide first which kind of caller is failing, because that picks your filter. A back-office job — a nightly lead import, a script that pauses agents, a status sync — logs in with a server credential, so filter by API User. An action the agent screen takes on a person's behalf is tied to that person, so filter by Agent User. Getting this right on the first pass saves you from scrolling past hundreds of healthy entries to find the handful that broke.

flowchart TD
  A[Integration broke] --> B[Set time range around the failure]
  B --> C{Requests present in log?}
  C -->|No| D[Caller never reached us: network or wrong URL]
  C -->|Yes| E[Filter by Function and Result]
  E --> F{Result an error?}
  F -->|Yes| G[Read the error: bad params or auth]
  F -->|No, success| H[Problem is on the caller side]

What the patterns tell you

No entries at all for the affected Function means the request never arrived — a wrong URL, a firewall change, or a caller that broke before it sent anything. Entries with an error Result mean the request arrived but was rejected, usually bad parameters or a credential that changed. And entries that all show success while the integration still looks broken push the problem back to the calling system, which sometimes means a Webhook receiver on their side that's dropping your responses.

The API Log shows the structured function calls. If your integration drives behavior through URL hits — a dispo-call URL or a screen WEBFORM button — those land in a different place. The URL Log Report covers those, and the VICIdial troubleshooting playbook shows how to decide which log a given integration writes to.

On a VICIfast managed box the API log is enabled and retained, so when an integration breaks you have the receipts to prove whether the request even reached your dialer. See what's included on every plan.