Skip to main content

Overview

A Custom Object in LoginRadius is a flexible, schema-less data structure that can be associated with individual user accounts. It serves as a dynamic storage solution, allowing you to add fields and store varying data formats in real time. Custom Objects are ideal for storing large volumes of user-specific data that do not conform to a uniform structure, as the format can vary across users. These objects are managed through the Custom Object REST APIs, enabling the storage and retrieval of complex data types, such as nested objects and arrays, that cannot be effectively handled using standard Custom Fields.

Note: This feature is enabled and configured from the back end. If you want to have this feature enabled on your account, raise a request to the LoginRadius Support Team

Custom Object Schema Example

[
{
"Id": "5xxxxxxxxxxxxxxxxxf",
"IsActive": true,
"DateCreated": "2015-03-03T21:10:04.83Z",
"DateModified": "2015-03-03T21:10:04.83Z",
"IsDeleted": false,
"Uid": "5xxxxxxxxxxxxxxxxxa",
"CustomObject": {
"Test":[
{
"field1": "Data3",
"field2": "Data4",
"field3": "Data5"
},
{
"field11": "Data31",
"field21": "Data41",
"field31": "Data51"
}
]
}
}
]

Multiple Custom Objects and Records per User Profile

LoginRadius allows you to create multiple Custom Objects within a single user profile. This is particularly useful when organizing and storing distinct user data sets, such as activity logs, purchase history, preferences, and more. Segmenting data into multiple objects can enhance reporting, analytics, and personalized experiences.

In addition, each Custom Object can contain multiple records, enabling you to store a series of entries under a single object for a specific user. This is ideal for scenarios like maintaining a history of user actions, transactions, or changes over time—all within a structured, scalable format.

Note: If your use case requires more than one Custom Object per user, please submit a support ticket with your requirements.

Indexing and Querying Custom Objects

LoginRadius enables you to query Custom Object data for analysis, segmentation, and reporting by leveraging the Cloud Directory Custom Object APIs.

To use these APIs effectively, you must define a schema and configure indexing for the Custom Object. Indexing is a structured process that significantly enhances the performance of data retrieval operations by optimizing how data is stored and accessed.

Refer to the Cloud Directory Custom Object API documentation for detailed implementation guidelines.

Note: If you need to change an existing Custom Object schema or add new operations, please contact our support team at support@loginradius.com.

Custom Object API Workflow

LoginRadius offers a set of Custom Object APIs that allow you to create, read, update, and delete Custom Objects tied to a user's profile using UID or Access Token.

To use these APIs effectively, you’ll need the following parameters:

  • apikey: Your LoginRadius API Key
  • apisecret: Your LoginRadius API Secret
  • objectname: The name of the Custom Object
  • uid: The unique identifier for the user account
  • objectrecordid: The unique ID of a Custom Object record
  • Authorization: User's Access Token

Refer to the following section to perform the CRUD operations on Custom Objects.

You can refer to the following set of APIs for creating Custom Object either based on Token or UID:

Admin Console Configuration

Custom Objects must first be enabled and configured by the LoginRadius backend team. To request activation, please contact the LoginRadius Support team.

Once enabled, you can view, update, and delete Custom Objects directly from the Admin Console for individual user profiles. Follow these steps:

  1. Go to the Manage Customer section in the Admin Console.

  2. Search for the desired user and open their profile.

  3. Navigate to the Custom Objects tab.

  4. You will see the associated Custom Object(s) listed.

  5. Use the three-dot menu on the right to view, edit, or delete the object.

Parent and Child Accounts Using Custom Objects

In a typical implementation, an account is created using the Account Create API. Custom Objects are then used to define additional fields for storing custom data and establishing account relationships. For instance, both Parent and Child Accounts can have an "AssociatedAccounts" field containing UIDs to signify a many-to-many relationship.

  • One-to-Many Relationship (1:M): The Parent Account holds a "PrimaryAccountHolder" field, storing the UID of a Child Account with access to it.

  • Many-to-Many Relationship (M: M): The Parent Account contains a "ChildAccounts" field with an array of Child UIDs, while the Child Account stores the "ParentAccounts" field with a variety of Parent UIDs.

Follow the below-mentioned steps to implement Parent-Child Account Relationships:

  1. Creating the Parent Account:

    1. Generate a unique email (e.g., parentacct-342@example.com).
    2. Optionally, set a username.
    3. Call the Account Create API.
    4. Capture the Parent Account’s UID (e.g., 24490de9c54145a4818b0cb688a3f3e2).
  2. Creating the Parent Account's Custom Object:

    1. Use the Parent Account’s UID, call Create Custom Object API, and leave the fields blank at this point.
    2. Store the CustomObjectID for future use (e.g., 5d1680d35895633610b18ac7).
  3. Creating the Child Account:

    1. Create the Child Account via the Account Create API.
    2. Store the Child Account’s UID for reference (e.g., 8cfdc5ab1ef546169ff1231003caeefb).
  4. Creating the Child Account's Custom Object:

    1. Call the Create a Custom Object API with the Child Account’s UID.
    2. Add the ParentAccounts field, including the Parent Account’s UID.
  5. Updating the Parent Account’s Custom Object:

    1. Use the Custom Object Update API to perform this action.
    2. Use the Parent Account’s UID and CustomObjectID.
    3. Add the PrimaryAccountHolder field (Child UID) and the ChildAccounts array (Child UIDs).
  6. Retrieving Data:

    1. Use the Get Custom Object by UID to pull data for Parent and Child accounts whenever needed.