Add-on Usage Monitoring

After purchasing and using travel connectivity, a traveler visits Customer X’s portal to check the status of their add-ons.

Typical questions from the traveler include:

• How much of my data is remaining?

• When does my add-on expire?

• Which add-ons are currently active?

Customer X must

• Retrieve up-to-date usage and validity information for one or more add-ons

• Correlate this information with portal products purchased by the traveler

• Display remaining balance and expiration details in the portal in a clear and user-friendly way

How Usage Information Is Generated in SFT

Usage and balance information in SFT is updated when endpoint generates traffic and the traffic is rated and charged Important characteristics:

So Usage updates are not real-time but occur at variable intervals, depending on Traffic volume and speed

Fetch Endpoint Addon Details

Customer X retrieves add-on usage and validity information using the Get Endpoint Add-on Details API.

This API allows Customer X to query:

• All add-ons assigned to a specific endpoint using endPointId

• A specific add-on instance using its uniqueId

• All add-on instances of a specific Add-on Plan using its addonId

Retrieve All Add-ons for an Endpoint

Customer X can retrieve all add-ons assigned to an endpoint by querying using the endpointId.

This is typically used when:

• Displaying a list of all active add-ons

• Showing an overview of balances and validity periods

Retrieve a Specific Add-on Instance

Customer X can retrieve details for a specific add-on instance by querying using the uniqueId.

This is typically used when:

• Displaying detailed information for a single add-on

• Tracking a specific purchase, renewal, or instance

Retrieve All Instances of the Same Add-on Plan

Customer X can also retrieve all instances of a specific add-on plan assigned to an endpoint by querying using the addonId (i.e. the add-on plan identifier).

This option allows Customer X to fetch:

• All active instances of the same add-on type

• Multiple purchases or renewals of the same add-on made by the traveler

Key Data Output

The API response provides detailed information for each add-on instance assigned to an endpoint.

For every add-on instance, Customer X can retrieve the following key data:

Add-on Lifecycle Dates

• planStartDate
  Indicates when the add-on instance became active on the endpoint.

• planExpiryDate
  Indicates when the add-on instance expires.

These dates define the lifecycle of the add-on instance and are used to determine whether an add-on is currently valid.

Benefit Validity and Balance

Each add-on instance also contains benefit-level information, which may have its own validity period independent from the plan lifecycle:

• benefit.startDate
  The date when the benefit becomes usable.

• benefit.expiryDate
  The date when the benefit expires.
  This may differ from the plan expiry date, depending on configuration.

• actualBalance
  The initial benefit balance assigned to the add-on instance at activation (e.g. total data volume).

• balance
  The current remaining balance after usage has been consumed.

Counters, Thresholds, and Actions

If counters are configured for the add-on, the response may also include information such as:

• Usage counters and current values

• Configured usage limits or thresholds

• Associated actions triggered when thresholds are reached (e.g. throttling, blocking, notifications)

This information allows Customer X to:

• Accurately display usage status in the portal

• Anticipate add-on exhaustion or expiration

• Trigger renewal or top-up flows proactively

Backend Considerations

Customer X should:

• Use the stored endpointId to retrieve all add-ons

• Use the stored uniqueId to retrieve specific add-on instances

• Cache or refresh data based on portal usage patterns

Because usage updates are not real-time:

• Frequent polling is discouraged

• Reasonable refresh intervals should be applied