Update your Socialize timezone preference

Outcome

Change the original caller’s stored timezone while recognizing the current action’s unsupported advertised settings.

Action: app_topolo_socialize.preferences.update.

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:write. Review the exact preference change, validate and plan the confirmed mutation before execution.
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

• Read preferences.get first and retain the prior timezone. The current action supports timezone as an optional string; no user or workspace id belongs in its body.
• 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

PUT /api/user/preferences

{
  "timezone": "Asia/Dubai"
}

Interpret the response

• Only timezone intersects the current published update schema with the fields this pinned handler actually persists. Advertised theme, language, notifications, dashboard, calendar and analytics inputs are not read by the persistence code. Do not claim this action changes them.
• The handler also understands other top-level notification/date/time fields, but the current action schema does not declare those fields. Do not send undeclared keys or invent an action/transport workaround. A source/declaration correction belongs to the existing owner.
• The update returns {success:true,data:<preferences>}, without isDefault/id/userId. For an existing row it patches supported supplied fields using COALESCE and updates its timestamp; omitted fields preserve prior values.
• When no row exists, it inserts merged defaults plus the supplied values before reading back. Even {} or a body containing only ignored advertised fields can create a defaults row, or update an existing row timestamp. It is not a guaranteed no-op.
• The route does not validate an IANA timezone. Use a deliberately selected valid timezone and check persisted projection; an accepted arbitrary string is not proof of downstream timezone support. Empty timezone is ignored on existing rows; a new row can store empty but read back as UTC. Do not use empty/null as an invented reset operation.
• A successful response can fall back to computed defaults if the immediate read finds no row. Verify with preferences.get; success alone does not prove persistence.

Effects

• The route may insert or update the authenticated user’s preference row, then re-read it. Source code shows no encompassing write/read transaction; a later500 can follow a committed write.
• No provider call, notification send, DND scheduler activation or theme/language/UI update is shown in this handler. Verify actual stored settings separately from downstream behavior.

Worked examples

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

Change the original caller’s timezone

Source-derived synthetic and unrun; assumes original user context and either a defaults-valued existing row or successful insertion from defaults.

Request:

{
  "timezone": "Asia/Dubai"
}

Illustrative response:

{
  "success": true,
  "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"
  }
}

Re-read preferences.get and verify the intended timezone and stored-row indication; do not infer notification or UI behavior.

Refusals and recovery

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

• Call preferences.get with the same original user and compare data.timezone to the reviewed value; check isDefault:false for a stored row. Preserve other preference values.
• After an error or interruption, read current state before any retry. A previously captured valid timezone can be restored only as a separately approved update; there is no published delete/reset-to-no-row action, and a compensating write does not restore original row absence or timestamps.

Related actions

• Read preferences
• Review the supported timezone change

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.