Overview

Getting started with the MyPreferences 3.0 Version 4 API is easy. Before diving in, take a moment to review the supported authorization options and understand how the API library is organized within the MyPreferences core framework.

Using API's

Refer to the Authorization section to discover the different authorization methods supported for accessing the MyPreferences API.

The MyPreferences API is a RESTful service that follows the principles of Representational State Transfer (REST). It exposes configuration objects and data as resources, each accessible through a unique URL, commonly referred to as an endpoint.

In general, the API supports the following request methods:

GET: To retrieve a resource

POST: To create a new resource

PUT: To update (overwrite) an existing resource

PATCH: To perform partial updates to an existing resource

DELETE: To delete a resource

To access the Swagger specification of the MyPreferences API, click here.

API Categorization

The API's are categorized into three separate sets with distinct functionalities based on the application's core framework: Experiences, Data, and Connectivity.

Data Categorization

In MyPreferences, data is organized into three core areas: Profiles, Preferences, and Consents. Together, these components form a unified customer profile, providing a comprehensive view of each individual’s preferences, consents, and zero-party data across all channels and interactions throughout their journey.

Profiles

The Profiles area stores a wide range of customer data, including names, contact details, group affiliations, interests, and various demographic and psychographic attributes.

Profiles also support multiple Alternate IDs, such as system or device identifiers, enabling you to uniquely identify individuals across different systems within your enterprise.

Preferences

The Preferences area captures all customer choices, including subscriptions, communication frequency, engagement channels, and preference attributes. It is designed with built-in rules to ensure the correct preference is honored, preferences are propagated appropriately, expiration is applied, and associated consents are enforced.

A complete preference history is maintained to support auditing and analytical use cases.

Consents

The Consents area acts as a centralized consent repository for storing and managing all customer consents. It supports unlimited granularity, allowing consents to be associated with an individual, device, or application, as well as linked to specific contact elements or preference communications.

Built-in rules enable consent propagation across similar contacts, expiration management, automatic notification when new consent versions are available, and full consent history retention for audit and analysis purposes.

Status Manager Addon:

MyPreferences customers can subscribe to the Status Manager 3.0 addon to enable real-time status updates for phone numbers and email addresses on profiles. This feature continuously scrubs contact data against Do Not Contact (DNC) lists to ensure compliance.

• Seamless enablement of National and State Do Not Contact lists, including Wireless Block Identifier, iConnectiv Wireless Portability, Telcordia TDS and others.
• Automatic archival of Do Not Contact preferences associated with phone and email when removed from DNC lists. For example, when a number is added to a DNC list, its calling status is updated in real time on profiles.
• Automatic revocation of consents associated with a preference whose phone number or email address gets added to a DNC list.
• Automatic updates of wireless status across all phone numbers.