If the PersonalizeWP REST API is not behaving as expected, check these areas in order.
1. Check the auth header
The current public API expects:
X-PWP-Auth-Token
If you are using an external origin, the token must match the exact origin you configured in Settings > Security > Authentication.
2. Check the origin
The allowed origin must match exactly, including:
httpsvshttpwwwvs non-www- subdomains
- port numbers in development
3. Check the request shape
Common request-shape mistakes:
- Sending
filtersas an array instead of an object onvisitor-activities - Reading the response body directly instead of reading
result.data - Omitting the visitor
uid
Correct visitor-activities filter shape:
{
uid: "VISITOR_UID",
filters: {
activity_type: "post",
object_type: "product"
}
}
4. Check whether the visitor exists yet
Many API calls depend on a known visitor UID. On the standard front end, PersonalizeWP stores this in local storage as pwp_tracked_user.
If you are building outside the standard runtime, make sure you are persisting and reusing a stable visitor ID.
5. Check that the underlying data exists
Examples:
visitor-segmentsreturns nothing if the visitor is not in any active segmentsvisitor-activitiesreturns nothing if no matching activity has been recordedvisitor-datareturns empty values for custom fields that are no longer registered
6. Check caching and optimization
If personalized behavior works inconsistently, confirm that PersonalizeWP runtime scripts are excluded from aggressive JS optimization.
See Caching Exclusions.
7. Check the current endpoints
The current public endpoints are:
/personalizewp/v1/activity/personalizewp/v1/visitor-data/personalizewp/v1/visitor-segments/personalizewp/v1/visitor-activities/personalizewp/v2/blocks/personalizewp/v1/variation-blocks/personalizewp/v2/blocks-pwd
If you are using older examples, make sure they still match the routes and headers used by the current plugin code.