Notifications and preferences

Read in-app notifications and update communication preferences.

Access labels such as Origin + Brand key + Customer are defined in Headers and access. Each endpoint ends in a Try it console; set the host and keys once in its Settings tab or on the overview.

Fetch user in app notifications

Method	URL path	Required access
GET	/api/v1/user/notification/logs	Origin + Brand key + Customer

Request fields:

Field	Type	Required	Rules / meaning
query.type	string	optional	Whitespace trimmed
query.limit	number	optional	—
query.offset	number	optional	—

Example:

curl -X GET "$BASE_URL/api/v1/user/notification/logs?limit=10&offset=0" \
  -H "Origin: $ORIGIN" \
  -H "api-key: $API_KEY" \
  -H "Authorization: Bearer $CUSTOMER_TOKEN"

Response: JSON with success: true and result containing the operation’s service data.

Source: app/v1/controller/customer_controller.js:1357 → fetchUserInAppNotifications; routes: routes/v1/customer_route.js:518; service: _fetchUserInAppNotifications (app/v1/service/customer_service.js:3033).

Get user preferences

Method	URL path	Required access
GET	/api/v1/user/preferences	Origin + Brand key + Customer

Request fields: no body, query, or path fields are read by this controller. Context comes from the headers/middleware above.

Preference data is scoped to the signed-in customer and current brand.

Example:

curl -X GET "$BASE_URL/api/v1/user/preferences" \
  -H "Origin: $ORIGIN" \
  -H "api-key: $API_KEY" \
  -H "Authorization: Bearer $CUSTOMER_TOKEN"

Response: JSON with success: true and result containing the operation’s service data.

Source: app/v1/controller/user_preference_controller.ts:10 → getUserPreferences; routes: routes/v1/user_preference_route.ts:30; service: _getUserPreferences (app/v1/service/user_preference_service.ts:12).

Update user preference

Method	URL path	Required access
PUT	/api/v1/user/preference	Origin + Brand key + Customer

Request fields:

Field	Type	Required	Rules / meaning
body.payload	array of object	yes	—
body.payload[].id	number	yes	—
body.payload[].email_consent	boolean	optional	—
body.payload[].sms_consent	boolean	optional	—
body.payload[].push_notifs_consent	boolean	optional	—
body.payload[].push_notifs_sound	boolean	optional	—
body.payload[].apn_consent	boolean	optional	—
body.payload[].in_app_push_notifs_consent	boolean	optional	—

body.payload is an array, not an object. Each item identifies the preference by id and supplies the consent fields to change.

Example:

curl -X PUT "$BASE_URL/api/v1/user/preference" \
  -H "Origin: $ORIGIN" \
  -H "api-key: $API_KEY" \
  -H "Authorization: Bearer $CUSTOMER_TOKEN" \
  -H 'Content-Type: application/json' \
  --data-raw '{"payload":[{"id":1,"email_consent":true}]}'

Response: JSON with success: true and result containing the operation’s service data.

Source: app/v1/controller/user_preference_controller.ts:29 → updateUserPreference; routes: routes/v1/user_preference_route.ts:40; service: _updateUserPreference (app/v1/service/user_preference_service.ts:103).

Related pages

• Batch Commerce API overview
• Notifications
• Implementation notes