Home
MATRIXX Subscriber Management API
Object Management
The following sections introduce how the various in-memory objects are managed.
Status Life Cycles
A status life cycle is a collection of object states, policies, and transition rules that are defined for a specific object type. You can define a status life cycle for user, device, subscription, group, and offer objects to customize the behavior of MATRIXX for your business processes. For example, a device life cycle can begin with a provisioned status, transition to an active status, and finally transition to an inactive status.
Status Life Cycle Definitions
A status life cycle defines a set of status values for a specific object class (device, subscriber, user, group). Each object class has one status life cycle. Status life cycles are defined in My MATRIXX and are loaded as part of pricing.
Status Life Cycle State Diagrams
The following state diagrams show the default status life cycle definitions for devices, subscription, and groups. In addition, a sample device life cycle definition demonstrates the addition of a custom status "provisioned." Notice that none of the state diagrams include self-transitions, which are not allowed.
Device Life Cycle State Diagram
The device life cycle state diagram shows the default status life cycle definitions for devices.

Welcome
MATRIXX Release Notes
MATRIXX Architecture
MATRIXX Installation and Upgrade
MATRIXX Configuration
MATRIXX Security
MATRIXX Integration
MATRIXX Diameter Integration
MATRIXX Call Control Framework Integration
MATRIXX TM Forum Integration
MATRIXX 5G Integration
MATRIXX 5G Event Streaming
MATRIXX Event Streaming
MATRIXX Administration
MATRIXX Web App Administration
MATRIXX Monitoring and Logging
MATRIXX Policy
MATRIXX Kafka CDR Consumer
MATRIXX Pricing and Rating
MATRIXX Pay Now
MATRIXX Subscriber Management
MATRIXX Subscriber Management API
- About Subscriber Management API
  MATRIXX Subscriber Management API provides information about the MATRIXX Engine APIs, including functions, syntax, and result codes, and the MATRIXX Engine REST and Java API implementations.
- Subscriber Management
  The following information is an overview of the SubMan APIs and architecture.
- Object Management
  The following sections introduce how the various in-memory objects are managed.
  - Subscription Management
    The subscription management APIs include the messaging required to operate on the subscription object (MtxSubscriberObject), which is a primary object for MATRIXX interactions.
  - Group Management
    The group management APIs include the messaging required to operate on the group object. The APIs include the messaging and data elements required to create, modify, associate, and query objects directly related to the group.
  - Device Management
    The device management APIs include the methods and functions required to operate on the device primary object. They include the data elements required to create, modify, and query devices, to add and remove a device from a subscription, and to delete a device from the Subscriber database.
  - User Management
    The user management APIs include the messaging required to operate on the user object, which is a primary object for MATRIXX interactions. The API bindings include the messaging and data elements required to create, modify, and query users and associate a user with a subscription. A user can be associated with zero or more subscriptions and groups.
  - Balance, Meter, and Wallet Management
    The balance management APIs include the messaging required to operate on a balance, meter, or wallet object. The primitives include the messaging and data elements required to create, modify, associate, and query objects directly related to a balance or meter, including their thresholds.
  - Product Offer and Bundle Management
    The product offer management APIs include the messaging to activate, purchase, cancel, and modify catalog items. You can identify a product offer by its object ID or the external ID assigned during pricing plan creation.
  - Catalog Item Management
    You can purchase, query, and cancel catalog items using the SubMan APIs.
  - Billing Cycle Management
    Billing cycles properties are configured during global system configuration and managed using the SubMan APIs with which you can create or change a subscription or group billing cycle.
  - Time Zone Management
    When you change a subscription or group time zone using the SubMan APIs, the change impacts wallet periodic balances, billing cycles, and _glossary/purchased-item_cycle.html.
  - Pricing Management
    The pricing management APIs return information about all aspects of pricing, including catalog items, balance templates, product offers, billing cycles, life cycles, notifications and so forth. You can also get status information for the currently-loaded pricing.
  - Data Migration
    Use the data import APIs to import data for users, subscriptions, groups, and devices and to import catalog item purchase information for a subscription. For example, create a subscription with a final status and a LastActivityUpdateTime and link that subscription to other objects (group, device, user, product offer).
  - Rehoming
    Rehoming is the process of moving a user, group, device, or subscription from one sub-domain to a different sub-domain in a multi-domain platform.
  - RS Gateway Bulk Operations
    The process_bulk_csv.py script reads comma-separated values (CSV) files to perform bulk REST operations through the RS Gateway.
  - Object Validity End Time
    The validity end time indicates the time after which querying an object again may return a different definition of the object.
  - Purchased Item Cycle Alignment
    When purchasing a catalog item, you can specify if the purchased item cycle is independent or aligned to a billing cycle, balance cycle, or a different purchased item cycle. The cycle to which a purchased item cycle is aligned is the master cycle.
  - Offer Life Cycle Profiles
    An offer life cycle profile consists of a set of offer statuses, a set of policies associated with each offer status that describe behavior that can be executed in this status, and a set of transitions that can have conditions defined that can trigger a transition and actions defined that are executed after the transition is performed. Both offers and bundles can have an offer life cycle profile defined. Use offer life cycle profiles to customize the behavior of MATRIXX for your business processes.
  - Status Life Cycles
    A status life cycle is a collection of object states, policies, and transition rules that are defined for a specific object type. You can define a status life cycle for user, device, subscription, group, and offer objects to customize the behavior of MATRIXX for your business processes. For example, a device life cycle can begin with a provisioned status, transition to an active status, and finally transition to an inactive status.
    - Status Life Cycle Execution
      The elements in a status life cycle are executed in a specific order. For example, a life cycle might define the following:
    - Status Life Cycle Definitions
      A status life cycle defines a set of status values for a specific object class (device, subscriber, user, group). Each object class has one status life cycle. Status life cycles are defined in My MATRIXX and are loaded as part of pricing.
      - Status Policies
        An object's status defines the policies available to it. By default, all policies are permitted.
      - Status Transition Actions
        Certain actions that can only occur during specific transitions.
      - Status Conditions
        Transition conditions determine when an automatic transition to a new status occurs. For example, after 30 days without activity, cause a transition to the Inactive status.
      - Status Activities
        Status activities indicate the eligible activities that can occur to trigger an auto-transition. Status activities are selected when the Delete Object status policy is selected.
      - Filter Transition Actions and Conditions
        When adding transition actions and conditions to a life cycle (either offer or status), optionally apply a filter to the condition to decide if it has been met or to an action to decide if it should be performed.
      - Status Life Cycle State Diagrams
        The following state diagrams show the default status life cycle definitions for devices, subscription, and groups. In addition, a sample device life cycle definition demonstrates the addition of a custom status "provisioned." Notice that none of the state diagrams include self-transitions, which are not allowed.
        Device Life Cycle State Diagram
        The device life cycle state diagram shows the default status life cycle definitions for devices.
        Subscription Life Cycle State Diagram
        The subscription life cycle state diagram shows the default subscriber life cycle definitions for subscribers.
        Group Life Cycle State Diagram
        The group life cycle state diagram shows the default status life cycle definitions for groups.
        User Life Cycle State Diagram
        The user life cycle state diagram shows the default status life cycle definitions for users.
        Custom Device Life Cycle
        The custom device life cycle state diagram shows the addition of a new status to the default life cycle definitions for subscribers.
    - Status Life Cycle Notifications
      Status changes in an object status life cycle trigger notifications for the status change, and can also cause notifications to be generated for balance, product offer, and bundle expirations, and product offer purchases, cancelations, suspensions, and resumptions.
  - Modifying Statuses
    Use the SubMan APIs to modify status values of subscriptions, groups, and devices. Status values are defined in object status life cycles.
  - Making Multiple Requests in One API Call
    You can perform multiple engine requests (MtxRequestMulti) using a POST call to the RS Gateway. For example, one request can create a subscriber, create a device, and associate the device with that subscriber.
  - SubMan Operation Search Terms
    In many of the SubMan API methods, you must specify a search term that identifies an instance of a specific object.
  - Getting Subclasses of MDC Definitions
    For each MDC definition, you can get a list of all classes that have that class as its base class.
  - Getting Subtype Code Values
    For each subtype, you can get a list of all codes and their values.
  - Adding Event Data in SubMan Requests
    You can pass data in SubMan requests in the MtxApiEventDataExtension MDC to be included in EDRs.
  - Working with Custom MDCs
    Custom MATRIXX Data Containers (MDCs) can stand alone or extend system MDCs or other custom MDCs. Use private MDCs to extend subscribers, devices, and purchased product offers with custom parameters. You can set values for these parameters in SubMan API calls within the <attr> element of the request XML in the REST APIs or in the Attr field of the Java APIs.
  - Message XSDs
    You can query the RS Gateway for XSD definitions for MDCs that can be used by third-party applications to validate their XML.
- SubMan API Reference
  The SubMan API reference includes SubMan API and MDC descriptions.
- REST API Management
  RS Gateway supports the REST API bindings for accessing subscriber data in MATRIXX Engine. RS Gateway consists of an rsgateway application and a set of REST APIs.
- REST API Reference
  This part describes how to use the REST API bindings to interface with MATRIXX Engine.
- Java API
  This part provides an overview of how to use the Java™ API binding for the SubMan v3 API as an interface to the MATRIXX Engine.
MATRIXX Business API SDK
My MATRIXX Help
MATRIXX Backoffice Customer Tool Help
MATRIXX Third-Party Licenses
Glossary

Device Life Cycle State Diagram

The device life cycle state diagram shows the default status life cycle definitions for devices.

Figure 1 shows the default device life cycle state diagram. Each state represents a status defined My MATRIXX. Status transitions are represented by the directional lines. Status transition actions are displayed next to the transitions. Status policies that are not allowed when a device is in a specific state are listed in red on the status itself. By default, all status policies are allowed. By default, there are no defined status conditions. Each transition is initiated by a SubMan operation.

Note: Only offers that are configured as "Can Be Suspended" in the product offer template are suspended.