Reporting, Exports and Channel Alerts

The platform updates reports as messages and campaigns are processed. Reporting users can view one client's activity or compare activity across clients without slowing down message sending.

How report data is organized

Reports use two main types of records:

Report data	One record for	Used in
Message details	One SMS recipient	CDRs, campaign recipient details, dashboards, summaries and channel alerts
Campaign summary	One campaign	Campaign lists, status totals and cost totals

When a message is submitted, the report stores details such as the client, content, route, SMS parts and price. When delivery finishes, it adds the final status, delivery-report errors and completion time. Campaign reports are also updated as recipient results change.

Reporting events can arrive more than once or in a different order. The platform combines them without creating duplicate records or replacing a final delivery result with older information.

Reports

Message details (CDR)

A communication detail record (CDR) shows one row for each recipient. It can be filtered by:

• client;
• message submission dates, including both the start and end dates;
• mobile operator;
• delivery status (DLR);
• phone number (MSISDN);
• sender ID.

CDR rows can include message text, phone number, client IP address, provider reference, status, error and cost. This is sensitive personal and business data, so access, storage time and exports should be controlled.

Campaign summaries and recipient details

The campaign view shows campaign details, status, recipient counts, SMS parts, estimated and final cost, and sending times. Reporting users can select a campaign to view the result for each recipient.

Campaign recipient totals count phone numbers. The totalSms, deliveredSms and failedSms values estimate SMS parts by multiplying the recipient count by the campaign's part count. Personalized messages can have different lengths, so use recipient details or the SMS summary when exact part totals are required.

Dashboard

Dashboard totals and daily trends count SMS parts, not phone numbers:

totalSms = deliveredSms + failedSms + pendingSms

The dashboard includes campaigns and direct messages. Users can filter it by client and date range, including both the start and end dates.

SMS summary

The SMS summary groups results by date, mobile operator and country. It shows:

• recipient count;
• delivered and failed recipients;
• SMS parts;
• average charge per SMS part;
• total charges.

Detailed SMS summary

This view groups results by client, username, gateway or channel, and mobile operator. It shows delivery in two ways:

• totalDelivered and totalFailed show the provider's response when the message was sent;
• infozillionDelivered and infozillionFailed show the later Infozillion delivery-report result when delivery reports are enabled.

It also shows recipient count, SMS parts, average cost, total cost and sending success rate.

Filtering and paging

• Platform reporting users can omit clientId to include all clients. Other users should only have access to their own client data.
• Date filters include both the start and end dates.
• Request page numbers start at 0, while currentPage in the response starts at 1.
• Page size defaults to 50 when the requested value is zero or negative, and the maximum is 200.
• Reports are updated in the background, so new message results may take time to appear.

Downloading CSV reports

Every report can be downloaded as a filtered CSV file. A CSV download includes all matching rows and is not limited by the page selected in the report view.

CSV downloads include:

• UTF-8 support so spreadsheet applications display Bangla correctly;
• safe handling of commas, quotation marks and line breaks;
• protection against values being run as spreadsheet formulas;
• case-insensitive excludeColumns options for removing unwanted columns;
• automatic ignoring of unknown column names;
• batch processing for large CDR and recipient downloads to reduce memory use.

Very large campaign exports can take longer and should be monitored for interrupted downloads.

Channel failure alerts

The platform counts final message failures for each client and channel during a rolling time window.

These results count as failures:

• FAILED
• REJECTED
• EXPIRED
• UNDELIVERED
• INVALID_MSISDN
• DND
• NOT_AVAILABLE

flowchart TB
    Failure[Failed recipient result is recorded]
    Count[Count the recipient once for its client and channel]
    Limit{Failure limit reached?}
    Recent{Was an alert sent recently?}
    Watch[Keep watching for failures]
    Alert[Send the configured channel alert]

    Failure --> Count --> Limit
    Limit -- No --> Watch
    Limit -- Yes --> Recent
    Recent -- Yes --> Watch
    Recent -- No --> Alert

Hold "Ctrl" to enable pan & zoom

Each recipient is counted only once, even if the same reporting update is received again. By default, an alert is created after 100 failures within five minutes. After sending an alert, the platform waits 15 minutes before sending another. These settings apply across the platform unless changed during deployment.

The platform saves an alert before trying to deliver it. If delivery fails five times, it pauses the alert. It can try again after the waiting period for up to three rounds; an operator must handle alerts that still fail.

If the failure counter is unavailable, report updates continue, but an alert may be missed during that time.

Alert limits

• The same alert settings apply to every client and channel.
• One webhook URL is configured for the platform. If it is blank, alerts are published to the internal client.channel-alerts topic instead.
• The optional webhook X-Api-Key must be kept secret.
• A webhook may receive the same alert more than once, so the receiving system should ignore duplicates using the event or alert ID.
• The platform does not provide a screen or API to view, acknowledge or manage alerts.
• NOT_AVAILABLE counts as a channel failure even though it does not receive an automatic refund.

See the Reporting and Export API and client-service architecture.