Build a missed-call follow-up list from IllyVoIP call history

Use the IllyVoIP Calls API to collect incoming records that explicitly indicate no answer, then create a private follow-up list for staff. Keep technical call outcomes separate from your team’s work status. A failed call is not automatically a missed customer call, and a matching phone number does not prove who called.

Use a backend with authorized account API access and keep X-Api-Key out of browser code. The API base is https://api.illyvoip.com. Check HTTP status and the JSON result. Examples below are request templates, not records of completed transactions.

1. Choose the authorized history scope

Request GET /api/v1/calls for each SIP identity the account may access. Set sip_user_id explicitly; omitting it uses the account’s default identity rather than every line. The API is account-owner scoped, so your application must restrict the resulting list to staff who may see those records.

Use days from 1 to 31, limit up to 500 and the returned cursor for continuation. Days are UTC calendar days, including today. Keep the same filters for a traversal, follow pagination.has_more and next_cursor, and store each page before advancing. Do not copy Portal date filters or an invented “missed” filter into this API.

2. Classify returned records conservatively

Read direction, status, failure_reason_code and available hangup_cause. A clear candidate has incoming direction, failed status and the public no-answer reason. Keep other outcomes for separate review rather than turning busy, rejected, unavailable or unknown records into the same promise.

def follow_up_class(call):
    direction = call.get("direction")
    if direction == "outgoing":
        return "outside_incoming_list"
    if direction != "incoming":
        return "review_unknown_direction"
    if call.get("status") == "completed":
        return "completed"
    if (call.get("status") == "failed"
            and call.get("failure_reason_code") == "no_answer"):
        return "no_answer_candidate"
    return "review_other_outcome"

A zero duration alone is not a no-answer classifier. The API can present an answered zero-duration record as completed, and a generic failed result does not reveal a unique cause. Preserve null and unknown fields instead of manufacturing a failure explanation.

3. Confirm a usable callback destination

1. Use the returned incoming from or corresponding peer number as context.
2. Keep anonymous, null and unparseable values out of an automatic dial action.
3. Normalize complete telephone numbers with a known context; never infer a destination from the last digits.
4. Show an authorized contact match only after access checks and ambiguity handling.
5. Let staff review the reason for contact and any restrictions before placing a call.

This list does not itself authorize contacting a person or prove caller-ID ownership. An incoming record on one identity may be part of a wider routing attempt that another endpoint answered. Where the API does not establish that relationship, keep the item for review; do not merge records merely because their numbers and times are similar.

4. Store call evidence and staff decisions separately

Use account scope and the complete public call_id as the evidence identity. Preserve its CALL- prefix and all characters. Store source SIP identity and UTC started_at for context. Repeated imports should update the same source record without adding another follow-up item.

Maintain your own work states, such as Needs review, Assigned, Contact attempted, Resolved and No callback needed. Record the responsible operator and reason. These are application states, not public IllyVoIP call-status values. Do not invent an API endpoint to mark a history row read or to clear the Portal’s unread badge.

5. Refresh without erasing completed work

1. Run overlapping history windows to pick up later reporting updates.
2. Upsert the latest technical record by its public ID.
3. Preserve staff notes, assignments and deliberate resolution decisions.
4. If a record’s technical outcome changes, flag it for review rather than silently reopening a completed task.
5. Keep failed or partial syncs distinct from a completed empty result.

A call disappearing from a later time window is not a deletion or resolution signal. Keep your retention policy separate from the rolling API window. Cursors are short-lived traversal tokens, not permanent bookmarks; restart an expired traversal and reconcile by public ID.

6. Check classification and human follow-up

Test incoming no answer, outgoing no answer, completed zero-duration calls, busy, rejected, unknown direction and anonymous callers. Test a repeated page, a later status correction and two staff members attempting to claim the same item. Confirm the list creates no automatic paid callback and leaves the Portal unread state alone. A real follow-up call remains a deliberate authorized action through the normal phone workflow.

Related guides

• Export call history and retrieve available recordings with the IllyVoIP API
• How to Read and Understand Your VoIP Call Reports (CDR)
• Use IllyVoIP calling inside your CRM

Reference

Current instructions and technical reference: IllyVoIP API documentation.

Reviewed 13 October 2026 against the current IllyVoIP controls, implementation and applicable references. Available options depend on account permissions and service state.