Overview
Getting started with the MyPreferences 3.0 Version 4 API is easy. Before diving in, review the supported authorization options and how the API library is organized within the MyPreferences core framework.
See the Authorization section for the different authorization methods supported for accessing the MyPreferences API.
Using API's
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, also referred to as an endpoint.
The API supports these request methods:
GET | Retrieve a resource |
POST | Create a new resource |
PUT | Update (overwrite) an existing resource |
PATCH | Partially update an existing resource |
DELETE | Delete a resource |
Note: Within the Data API collection, the UpdateProfile is a POST-based method built specifically to update a profile efficiently. This lets client-facing apps modify a profile directly, without retrieving it first.
The full Swagger specification of the MyPreferences API is available here.
API Categorization
MyPreferences APIs are organized into three sets, based on the application's core framework: Experiences, Data, and Connectivity.

Data Categorization
MyPreferences organizes data into three areas: Profiles, Preferences, and Consents which together form a unified customer profile: a comprehensive view of each individual's preferences, consents, and zero-party data across every channel and interaction.
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, so you can 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's built with rules to ensure the correct preference is honored, preferences propagate 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 the 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 on profiles in real time.
- Any consent tied to a preference whose phone number or email address gets added to a DNC list is automatically revoked.
- Automatic updates of wireless status across all phone numbers.
Base URL
Production:
Sandbox: