How to read the URL Log Report to debug webhook and webform calls

When a dispo URL silently fails or an agent's WEBFORM button opens the wrong page, you don't have to guess. VICIdial writes a record every time it fires an outbound URL, and the URL Log Report is where you read those records back. This post walks through what it captures and how to use it to debug a broken integration.

What the URL Log Report actually records

The report shows one row for each URL (in VICIdial) the system requested over a date and time frame you choose. That includes the Dispo Call URL — the request VICIdial sends after an agent sets a Disposition — and agent-screen WEBFORM button clicks, where the agent opens a Web form populated with lead data. Each row can include any or all of the URL scripting fields, so you see the exact address that went out, not just that something happened.

This matters because a Webhook failure rarely throws an error the agent will notice. The call dispositions fine, the screen moves on, and the third-party CRM never receives the record. The only durable evidence is the logged request, which is exactly what this report surfaces.

Reading a single request row

Start with the full URL string. Because VICIdial logs the whole address after it substitutes the scripting fields, you can read the real values it sent: the lead ID, phone number, agent user, and any custom parameters you wired into the script. If a field came through empty or as a literal placeholder like --A--phone_number--B--, the substitution failed and your script is the problem, not the network.

• Empty or placeholder values in the logged URL → fix the script field name, not the endpoint.
• A correct-looking URL that still failed → the problem is at the receiving server, so test that endpoint directly.
• No row at all for the time the agent dispositioned → the URL never fired, so check the campaign's Dispo Call URL setting.

A simple decision path

flowchart TD
  A[Webform or dispo URL fails] --> B{Row in URL Log Report?}
  B -->|No| C[URL never fired: check campaign config]
  B -->|Yes| D{Values substituted correctly?}
  D -->|No| E[Fix script field names]
  D -->|Yes| F[Test the endpoint directly]

Tying it to the agent and the lead

Each request can be tied back to the Agent who triggered it and the Lead it carried, so when one rep reports a broken WEBFORM you can filter to just their activity and compare a working request against a failing one side by side. That comparison is the fastest way to spot a single bad parameter.

If you're chasing a problem across the whole flow — call to disposition to outbound request — pair this with the rest of the VICIdial troubleshooting playbook. And when the URL itself is firing correctly but the data inside it looks wrong, the API Log Report shows the matching inbound side from VICIdial's own API.

When the data is fine but the platform isn't

Sometimes the URL Log proves your config is correct and the failures are intermittent — which points at the box, not the script. On a server that's overloaded or running on thin hardware, outbound requests time out under load. If that's your pattern, the fix is more headroom. VICIfast runs every dialer on a dedicated VPS so a busy campaign doesn't starve your webhook calls — see our plans for the per-server sizing.

Read the URL Log Report first, confirm the request fired with the right values, and you've already cut the problem in half: either the script, the endpoint, or the box. Each of those has a clear next step.