How Developers Can Use MYLO Call Events and Reporting APIs

MYLO reporting APIs let a business application answer practical questions: which campaign ran, which customers were attempted, what happened to each call, which run produced the result, and whether an authorised recording is available. Developers should model these relationships explicitly. A flat export of phone numbers and generic statuses loses the context needed for trustworthy dashboards, CRM updates, reconciliation, and customer follow-up.

Keep Analytics Separate From Operational Truth

A warehouse may reshape MYLO data for trends, but it should preserve source identifiers and extraction time. Aggregations, labels, and forecasts are derived views, not replacements for the current MYLO record or live Asterisk evidence. When a dashboard and operational view disagree, expose the freshness and mapping difference before changing customer workflow.

Test Failure and Repair Paths

Production testing should include duplicate events, delayed events, a consumer restart, expired authentication, forbidden resources, an empty page, a partially completed run, and a call whose customer and agent legs differ. Confirm that replay does not double-count calls or create duplicate CRM activities. Confirm that the reconciliation process repairs a deliberately skipped notification.

Keep a small set of authorised reference scenarios with expected relationships and metric results. Re-run them after contract or mapping changes, then compare call-level evidence before accepting an aggregate difference. Avoid copying real production recordings or full customer lists into test systems merely to make fixtures convenient.

Operate the Integration as a Product

Assign an owner for authentication, schema changes, data quality, reconciliation, and incident response. Monitor freshness, unresolved calls, permission failures, pagination errors, and drift between event-derived state and retrieved reports. Alert on actionable conditions, not every expected no-answer call.

Document how to stop ingestion safely, rotate the token, rebuild a bounded period, and prove that totals reconcile afterward. Reporting is trustworthy when the team can explain a number, reproduce it from supported resources, and repair processing without changing MYLO telephony history.

Use the Current Catalogue as the Contract

Start from the authenticated MYLO API page and controlled /api/v1/catalog. The established reporting hierarchy includes campaign, customer, call, run, run-report, and recording resources. Exact schemas, filters, allowed values, pagination, permissions, and error responses must come from the current backend contract, not from this explanatory article.

The documented paths can include GET /api/v1/campaigns, GET /api/v1/campaigns/{campaign_id}, its customer, call, and run collections, GET /api/v1/campaigns/{campaign_id}/runs/{run_id}/report, GET /api/v1/calls/{call_id}, and GET /api/v1/recordings/{recording_id}. Use only endpoints exposed to the authenticated user.

Understand the Reporting Hierarchy

A campaign is the durable business definition. Its customer collection represents the prepared audience and customer-level state. A run represents one execution period of that campaign. Calls are individual telephony attempts and may contain more than one leg. A run report aggregates the appropriate business outcomes without replacing the underlying records.

Keep these identifiers separate in your database. One campaign can have several runs; one customer can have several attempts; one call flow can create a customer leg and an agent leg; and one call can relate to a recording. Treating campaign ID, run ID, customer ID, call ID, channel ID, and recording ID as interchangeable causes duplicate counts and unsafe retries.

Choose the Right Resource for the Question

Use the campaign list for discovery, the campaign detail for definition and high-level state, the customer collection for audience-level progress, the call collection for attempts, and the run collection for execution history. Use the run report when the business wants a bounded summary for one execution. Retrieve a call directly when investigating its detailed lifecycle.

Do not make a dashboard fetch every detailed call whenever a summary endpoint answers the question. Conversely, do not use an aggregate report to decide whether a specific customer was reached. Selecting the smallest appropriate resource improves performance, privacy, and the accuracy of the conclusion.

Consume Call Events as an Ordered History

A call event should describe an observed transition tied to a stable call and, where applicable, leg identifier. Useful consumers retain the event identity, type, source timestamp, ingestion time, related campaign and run, and bounded outcome data. They do not flatten every notification into a single mutable “status” before preserving history.

Design for duplicate delivery and delayed observation. Applying the same event twice must not duplicate a CRM activity or customer follow-up. An older event arriving late must not overwrite a newer confirmed outcome. When ordering is uncertain, preserve the conflict and retrieve the current call record rather than guessing.

Reconcile Events With Retrieval

Events are useful for timely processing; reporting endpoints are useful for confirmation and repair. Store a cursor or other documented continuation state, then run a bounded reconciliation job that retrieves calls or run results for the period since the last successful checkpoint. Follow the actual pagination contract and stop conditions shown in the API catalogue.

Make checkpoints durable only after the application has committed all corresponding records. If a worker stops between receiving and saving an event, it should safely process that event again. If an event stream or consumer is temporarily unavailable, reconciliation should restore the business view without creating calls or changing MYLO state.

Keep Leg-Level Outcomes Intact

In a customer-first campaign the customer may answer before MYLO attempts an agent. If the agent then fails to answer, the customer contact occurred even though the bridge failed. In an agent-first flow, the customer may never have been called. Both could be reduced to “not connected,” but their customer impact and retry decision are different.

Store customer-leg, agent-leg, bridge, IVR, and final business outcomes as separate fields when the contract provides them. Derive dashboard categories through documented rules and retain the underlying MYLO values. Never retry a customer merely because the agent leg failed.

Build Reports That Explain Their Scope

Every operational report should state the campaign, run or date range, time zone, generation time, filters, and whether ongoing calls are included. Counts should reconcile to their population: total prepared customers, attempts, reached customers, bridged calls, IVR completions, no-answer results, failures, excluded records, and unresolved items as applicable.

Define each metric in business language. “Answered” may refer to one call leg, not a completed conversation. “Completed” may mean the telephony operation ended, not that a sale or appointment occurred. Keep MYLO operational outcomes separate from CRM dispositions entered by an agent or downstream application.

Handle Pagination, Time, and Change

Use the pagination fields and limits in the live contract. Do not assume a response is complete because it returned successfully. Capture time zones and use stable identifiers as tie-breakers when pages span concurrent activity. A reporting integration should tolerate new optional fields while refusing to silently reinterpret a changed required field.

Record the API version and the last successful reconciliation checkpoint. Test contract changes against non-production data before deployment. When a field is unknown or temporarily absent, retain that distinction; empty, zero, false, not applicable, and not yet known are not equivalent reporting states.

Retrieve Recordings Through Authorised APIs

A recording reference is not an invitation to browse storage. If the role is authorised and the recording exists, use the documented recording endpoint. The API should perform customer and role checks and return content or retrieval information without exposing raw filesystem paths.

Recording policy, notice, consent, access, retention, and deletion must be defined by the business for its jurisdictions and use case. Keep audit evidence of access, avoid copying audio into analytics systems unnecessarily, and never expose a recording merely because a developer can identify its ID.

Secure the Reporting Pipeline

Use a dedicated integration identity with least privilege and a protected Bearer token. Redact tokens, credentials, full phone numbers, recording locations, and unrelated customer data from ordinary application logs. Encrypt appropriate data in transit and at rest, restrict support exports, and define retention for both MYLO-derived records and local caches.

Tenant and role boundaries must be enforced by the server and respected by the client. The UI hiding a campaign is not an authorisation control. Do not use guessed identifiers to probe other resources, and do not create a global analytics identity merely for implementation convenience.

Developer Implementation Checklist

1. Read endpoint schemas and permissions from the current MYLO catalogue.
2. Map campaign, run, customer, call, leg, event, and recording identifiers separately.
3. Use events for timely updates and retrieval endpoints for reconciliation.
4. Make event processing and CRM updates idempotent.
5. Respect documented pagination, time zones, filters, and error semantics.
6. Preserve leg-level outcomes before deriving business categories.
7. State report scope and metric definitions beside the numbers.
8. Protect authentication, customer data, and recordings throughout the pipeline.

A dependable integration preserves relationships before it calculates summaries. That lets a developer explain where every number came from, repair missed processing, and make a safe customer decision without turning MYLO operational evidence into an ambiguous spreadsheet of statuses.