Topolo Docs Topolo Platform
Open workspace

Read your Socialize preferences

Read your notification/display preferences and distinguish computed defaults from stored settings.

Outcome

Read your notification/display preferences and distinguish computed defaults from stored settings.

Action: app_topolo_socialize.preferences.get.

Before you start

  1. Verify the original signed-in user, environment and intended context. These preferences are selected by the authenticated user id, not brand/workspace/organization filters. Do not supply another userId or forge authentication headers.
  2. Published application permission: app_topolo_socialize.accounts:read. This is a published read action; the preference handler queries without persisting computed defaults.
  3. Use the original human user session for this guide. The action metadata describes session-only behavior, but this handler only checks that an authenticated user id was supplied; no blanket API-key401 or role-bypass behavior is established here.

Identify the target

  • No preference-record id is required or returned. Input is exactly {}.
  • Keep normal credential/resource discovery separate. A generic catalog idPath is not proof this response contains an id/userId or that a workspace binding changes which user’s preference row is selected.

Request

GET /api/user/preferences
{}

Interpret the response

  • The pinned GET response is {data:<preferences>,isDefault:<boolean>}, without id/userId. isDefault:true means no stored user_preferences row was found and the complete defaults were computed for this read. It does not create a row.
  • isDefault:false means an existing row was projected; it does not mean every stored value differs from defaults. Boolean fields are coerced from stored values, and empty/missing time/timezone/date/time-format strings fall back to the source defaults.
  • Defaults are notification-specific, not a provider-delivery or scheduling receipt: emailNotifications/pushCampaignUpdates/pushPostPerformance/emailDailySummary/emailWeeklyReports/emailSecurityAlerts/scheduleCampaignReminders/schedulePostFailures true; pushTeamActivity/emailMarketing/doNotDisturb false; DND22:00–08:00; timezoneUTC; dateFormat MMM d, yyyy; timeFormat12h.
  • Reading these flags does not test whether any notifier, scheduler or downstream UI consumes them. No notification is sent by this handler.

Effects

  • The preference GET handler performs a SELECT and computes defaults if absent. It does not create or update preference rows or send notifications. Authentication and other middleware effects are not certified zero-write by this handler review.

Worked examples

All examples are source-derived, synthetic and unrun; they are not captured responses or permission to alter any real user’s settings.

Computed defaults with no stored row

Source-derived synthetic and unrun; assumes the original user has no stored row.

Request:

{}

Illustrative response:

{
  "data": {
    "emailNotifications": true,
    "pushCampaignUpdates": true,
    "pushPostPerformance": true,
    "pushTeamActivity": false,
    "emailDailySummary": true,
    "emailWeeklyReports": true,
    "emailSecurityAlerts": true,
    "emailMarketing": false,
    "scheduleCampaignReminders": true,
    "schedulePostFailures": true,
    "doNotDisturb": false,
    "dndStartTime": "22:00",
    "dndEndTime": "08:00",
    "timezone": "UTC",
    "dateFormat": "MMM d, yyyy",
    "timeFormat": "12h"
  },
  "isDefault": true
}

Interpret isDefault:true as computed fallback, not a preference-row creation receipt.

An existing stored preference projection

Source-derived synthetic and unrun; assumes an existing row with the illustrated timezone and default-valued other fields.

Request:

{}

Illustrative response:

{
  "data": {
    "emailNotifications": true,
    "pushCampaignUpdates": true,
    "pushPostPerformance": true,
    "pushTeamActivity": false,
    "emailDailySummary": true,
    "emailWeeklyReports": true,
    "emailSecurityAlerts": true,
    "emailMarketing": false,
    "scheduleCampaignReminders": true,
    "schedulePostFailures": true,
    "doNotDisturb": false,
    "dndStartTime": "22:00",
    "dndEndTime": "08:00",
    "timezone": "Asia/Dubai",
    "dateFormat": "MMM d, yyyy",
    "timeFormat": "12h"
  },
  "isDefault": false
}

Use the actual returned fields for the original user; no provider behavior is verified.

Refusals and recovery

StatusHandler codeNext step
400validation_errorMissing authenticated user context in this source handler. Re-authenticate through supported tooling and verify the original principal; never add a replacement userId/header.
500internal_errorPreserve request evidence and inspect current state/dependencies. No default-row creation was attempted by this GET handler.

Outer authentication, permission and rate-limit responses can differ. The reviewed handler’s status-to-code helper maps400 to validation_error and500 to internal_error; do not invent a source-specific401/422 refusal or a problem-details body here.

Verify the result

  • Inspect data and isDefault for the original caller. If isDefault:true, treat values as computed defaults rather than stored preference evidence. Do not create a row merely to convert defaults into proof.

Change log

2026-10-21: Added source-qualified user-preference guidance with actual default/stored semantics, supported schema/handler intersection, source-specific errors and synthetic unrun examples. Reviewed source f8e30bad6947f868302f24e9cb31b6a2bdd1fbf6; published catalog marker bc22ce7a2ceaa4396388794c4d42895c777bed76. No deployed association, preference mutation, notification or downstream-consumer result is claimed.