How to Sync Call Dispositions Out of VICIdial

After an agent finishes a call, they choose a disposition — a short outcome code like SALE, CBHOLD (scheduled callback), or NI (not interested) — that tells VICIdial what to do with the lead next Disposition. That outcome is exactly what your CRM CRM needs to update the contact record, trigger a follow-up workflow, or feed a sales dashboard. Getting dispositions out of VICIdial in near-real time closes the loop between your dialer and every other system that cares about call outcomes.

Where VICIdial stores disposition data

Every completed call writes a row to vicidial_log (outbound) or vicidial_closer_log (inbound and transferred calls). Key columns are uniqueid (Asterisk's unique call identifier), lead_id (the row in vicidial_list this call was for), status (the disposition code the agent selected), call_date, and length_in_sec. The lead's current status also updates in vicidial_list.status at the same time.

sequenceDiagram
  participant Agent as VICIdial Agent
  participant DB as vicidial_log
  participant Job as Your Sync Job
  participant CRM as Your CRM
  Agent->>DB: select disposition and save
  DB->>DB: write status to vicidial_log and vicidial_list
  Job->>DB: SELECT rows WHERE call_date > last_sync_time
  DB-->>Job: disposition rows with lead_id and vendor_lead_code
  Job->>CRM: update contact record via CRM API

Option 1 — direct database polling

The simplest approach for operators who control the database is a polling script that runs every minute via cron. It queries vicidial_log for rows newer than its last run timestamp, then calls your CRM's API for each row. Join on vicidial_list.vendor_lead_code to get back to your CRM's own record ID — this is exactly why you should send vendor_lead_code on every add_lead call Vendor lead code.

SELECT
  vl.lead_id,
  vl.status AS disposition,
  vl.call_date,
  vl.length_in_sec,
  vl.user AS agent_id,
  vll.vendor_lead_code
FROM vicidial_log vl
JOIN vicidial_list vll ON vl.lead_id = vll.lead_id
WHERE vl.call_date > '2026-06-28 10:00:00'
ORDER BY vl.call_date ASC;

Option 2 — the Non-Agent API update_log_entry call

If direct database access is not available, the Non-Agent API Non-agent API provides the update_log_entry function. This is primarily used to write data back in, but your integration can also use the lead_all_info function to pull the current status for a known lead_id after the call ends.

curl "https://your-server/vicidial/non_agent_api.php\
?source=crm-sync\
&user=6666&pass=1234\
&function=lead_all_info\
&lead_id=193715"

The response includes the current status field from vicidial_list and the last called_count. This works well if your CRM is already storing VICIdial's lead_id from the add_lead response. The tradeoff is you have to poll per lead, which is slow at scale — the direct SQL approach handles thousands of rows in a single query.

VICIdial lets you define custom disposition codes per campaign — short strings like SALE, NI (not interested), CBHOLD (scheduled callback), or DNC (do not call). Your sync job needs a mapping table that translates these short codes into whatever your CRM uses — for example, mapping SALE to a 'Closed Won' deal stage. Build that map as a config file in your sync process rather than hardcoded in the query, so you can add new codes without redeploying.

For callbacks — leads where the agent set a CBHOLD disposition — VICIdial also writes a row to vicidial_callbacks with the requested callback date and time. If your CRM can schedule follow-up tasks, pull from that table as well and create a task with the correct datetime so agents see it on both sides. Join on vicidial_callbacks.lead_id to get back to the lead record. The callback date column is callback_time (a datetime field) and the assigned agent is in callback_user.

When you sync, also capture length_in_sec from vicidial_log. Talk time is a signal your CRM sales dashboards will want alongside the outcome code. A disposition of SALE that came off a 90-second call tells a very different story from one off a 12-minute call. Store both so your operations team can analyze what call length predicts the best outcomes for each campaign. Joining vicidial_log with vicidial_list on lead_id gives you the full picture: phone number, agent, disposition, call duration, and the original CRM identifier via vendor_lead_code — everything you need to update the CRM record and close the integration loop.

A lead is one record in your calling data — a phone number plus the attached name, address, and notes Lead. Once you have dispositions flowing back to your CRM, you can also update the lead's data in VICIdial from the CRM side using the update_lead function. Read how to update a lead with the update_lead API for that direction. For the overall API picture, start with the VICIdial API and AGI overview.

If you want a VICIdial box where the Non-Agent API is already configured behind HTTPS and ready to accept your sync job from day one, every VICIfast plan provisions a production-ready server in under 40 seconds.