How to change a call's status with update_log_entry

An agent dispositions a call wrong, or your outside system marks a deal as won after the call already closed. Now one call log row in VICIdial shows the wrong outcome. You do not want to open the admin screen and hunt for it by hand. You want to fix it from your own app. The update_log_entry function lets you do exactly that.

It is part of the Non-agent API, the back-office set of VICIdial calls that act on the database rather than on a live agent. This particular call updates the status, the short code that records how a call ended, on a single row of the call log, and it works for both outbound and inbound (closer) log records.

The four fields you must send

Beyond the usual user and pass, the call needs four things to find the right row and change it:

• source - a short label, up to 20 characters, describing what made the call.
• call_id - either the Asterisk uniqueid (the unique Asterisk call identifier) or the 20-character VICIdial call ID.
• group - either a Campaign ID (for an outbound call) or an Ingroup group ID (for an inbound call). This tells VICIdial which log table to look in.
• status - the new Status (lead status) you want the record to carry.

Here is the full call as a single URL:

curl "http://server/vicidial/non_agent_api.php?source=test&user=6666&pass=1234&function=update_log_entry&group=SALESLINE&call_id=Y2010309520000000234&status=SALEX"

On success you get a line that begins with SUCCESS and echoes the call ID, the old status, and the new one. The change is recorded against that one call only.

Two error responses are worth watching for so you can tell a real failure from a no-op. NO RECORDS FOUND means the lookup did not match any row at all, usually because the call_id and group point at different tables. NO RECORDS UPDATED is subtler: the row was found but already carried the status you asked for, so nothing changed. Treat the second one as harmless and the first as a bug in how you built the request.

There is also a hard ceiling on how much work the call will do: it analyzes at most ten million records when it searches. On a busy box with years of history that limit matters, which is another reason to pass an exact call_id rather than hoping a loose match lands on the right row.

How the call flows

sequenceDiagram
  participant App as Your App
  participant API as non_agent_api.php
  participant DB as Call Log Table
  App->>API: update_log_entry call_id group status
  API->>API: Check permission
  API->>DB: Find row by group and call_id
  DB-->>API: Matching record
  API->>DB: Set new status
  DB-->>API: Updated
  API-->>App: SUCCESS RECORD HAS BEEN UPDATED

What it does and does not touch

This call changes the status on the call log row, the historical record of that one attempt. The status here is the same idea as a Disposition, the outcome code an agent picks when wrapping a call. It does not change the lead's own status field. If you want to fix the lead record so the next dialer pass behaves differently, use the update_lead call instead, covered in our guide to update_lead. The two often go together: update_log_entry corrects the history, update_lead changes what happens next.

One detail worth knowing: a closer record is the log entry for an inbound call handled by a Closer agent, so passing an in-group group_id is how you reach those rows. Outbound rows need the campaign ID. Mix them up and the lookup fails.

For the bigger picture of how every back-office call fits together, read the VICIdial API and AGI overview. And if you would rather not run and patch the dialer yourself, VICIfast hands you a managed VICIdial box with the API ready to call - see our plans to get started.