You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem description
In the relation to the common notification API issues#8
Subscribe/notify API pattern puts API client in a passive role – it has subscribed and expects being notified when something happens (SimSwap for given MSISDN, device leaves a location etc).
However, the subscriber owning given MSISDN (or a device) can terminate their contract or move to another MNO keeping their MSISDN
MNO must inform API client about this event as well, to allow it to act accordingly.
Possible evolution
One can suggest at least 2 approaches to solve this:
Each Camara API is obligated to inform their clients about contract termination using its notification channel (use same end point as it uses for “regular” notifications)
A centralized API to be introduced which an application provider should use to be informed about significant changes related to MSISDNs and devices (contract terminated/suspended/resumed/moved etc)
Since a common approach is selected, all Camara APIs must use it.
The text was updated successfully, but these errors were encountered:
To add a clarification, as of now our pattern follow the first approach mentioned
Each Camara API is obligated to inform their clients about contract termination using its notification channel (use same end point as it uses for “regular” notifications)
Problem description
In the relation to the common notification API issues#8
Subscribe/notify API pattern puts API client in a passive role – it has subscribed and expects being notified when something happens (SimSwap for given MSISDN, device leaves a location etc).
However, the subscriber owning given MSISDN (or a device) can terminate their contract or move to another MNO keeping their MSISDN
MNO must inform API client about this event as well, to allow it to act accordingly.
Possible evolution
One can suggest at least 2 approaches to solve this:
Each Camara API is obligated to inform their clients about contract termination using its notification channel (use same end point as it uses for “regular” notifications)
A centralized API to be introduced which an application provider should use to be informed about significant changes related to MSISDNs and devices (contract terminated/suspended/resumed/moved etc)
Since a common approach is selected, all Camara APIs must use it.
The text was updated successfully, but these errors were encountered: