Addons Creation
Addon Plans are the next configuration element Customer X needs to define.
An Addon Plan represents a commercial product that Customer X offers to travelers through its portal.
Each Addon corresponds to a specific benefit (for example, data volume and validity) and a specific geographical scope.
Addon Plans must be created in advance before they can be sold or assigned to endpoints.
Purpose of Addon Plans
Customer X uses Addon Plans to:
Define purchasable connectivity packages
Control where and how traffic can be generated
Enforce limits such as volume, validity, and throttling
Each Addon Plan exposed in the portal maps directly to one Addon Plan in SFT.
Relationship Between Addons and Rate Zones
Every Addon Plan is linked to a specific RateZone.
This relationship defines:
Where the Addon can be used
Which networks are eligible for traffic when the Addon is active
Rate Zones must therefore exist before creating Addon Plans.
Example Scenario
Customer X wants to offer travelers an Addon with the following characteristics:
30 GB of data
Valid for 7 days
Usable only in Country A
To implement this in SFT:
A Rate Zone is created for Country A, including all relevant networks
An Addon Plan is created with:
A data benefit of 30 GB
A validity period of 7 days
The Rate Zone for Country A assigned
When a traveler purchases this Addon via the portal, Customer X assigns the Addon Plan to the traveler’s endpoint.
Configuration Considerations
Addon Plans support a wide range of configuration options, including:
Benefit volume (e.g. data, SMS)
Benefit validity period
Re-subscription rules
Throttling behaviour
Charging and recurrence settings
These parameters allow Customer X to model different commercial offerings and lifecycle behaviours.
All detailed configuration options are documented in the Plan API reference.
When Addons Are Applied
Addon Plans are not active by default.
They become effective only when:
A traveler purchases the Addon via the portal
Customer X assigns the Addon to the corresponding endpoint
Addon Plans can be configured to activate in different ways, depending on the commercial model.
An Addon may:
Become active immediately upon assignment to an endpoint, or
Activate on first usage, when the endpoint generates traffic that matches the Addon’s eligibility criteria
The activation behaviour is defined as part of the Addon configuration and applies automatically when the Addon is assigned.
Multiple Addons may be assigned to the same endpoint, and each assignment is tracked independently.
APIs Used
Addon Plans are created and managed using the Plan APIs.
The primary API used for Addon creation is:
Create Plan API (Plan type: Addon)
(Refer to the Plan API reference page for full details on available parameters.)
Integration Notes – Addon Creation
This section highlights the key input and output parameters relevant when creating Addon Plans in this scenario.
It does not replace the full Plan API reference.
For the complete list of available configuration options, refer to the Plan API reference page.
Key Input Parameters
Addon Plans support multiple configurable parameters.
In this use case, the most critical input parameter is:
benefit.rateZone
The identifier of the Rate Zone where the Addon is applicable.
This value must reference the Rate Zone ID returned during Rate Zone creation.
It ensures that the Addon benefit is only usable within the intended geographical scope.
Other Addon parameters (such as benefit volume, validity, activation behaviour, throttling, and recurrence) can be configured as required and are documented in the API reference.
Key Output Parameters to Store
The following output parameter must be stored by Customer X in its backend systems:
planId
The unique identifier of the Addon Plan.
This ID is required when:
Assigning the Addon to an endpoint
Managing or updating the Addon configuration
Customer X should maintain a mapping between portal Addon products and the corresponding planId.