ContentSync Logo

User Data Stores

Scope

User data is stored per user and per space. A JWT with a different user ID (using the sub_id or sub property) will receive different user data. User data requested across different spaces will return different user data even if the user ID and user store name are identical. User data requested across different environments of the same space, however, will return the same user data.

Modeling

User data requires the same strong typing as the content model. User data types are created and managed in the Content Sync backend. Once created, they can be stored and retrieved using the delivery APIs; please refer to the documentation pages for the delivery APIs for details.

Privacy and Compliance

You can restrict the regions that user data is stored in when creating a space. If, e.g., only the European Union should be allowed to store user data, the space must be assigned to the EU and have replication to other regions disabled.

Content Cloud is operated by Edge Box GmbH in Germany and follows all applicable privacy regulations, most notably GDPR.

If you are unsure about where specific data is hosted or would like to learn about hosting alternatives, please reach out to our support.

Request management

Request endpoints

Requests that include user data may only go to the live and preview endpoints. The CDN endpoint is optimized for caching which contradicts per-user data requests. Trying to load or update user data using the CDN endpoint will produce an error.

To optimize the performance and cacheability of requests, consider splitting requests into those requiring user data that go to live/preview endpoints and those that don’t require user data and can go to the CDN endpoint. Depending on the exact usage patterns and requirements, this can significantly improve request performance; requests that can go to the CDN should always go to the CDN.

Request regions

To maximize consistency, requests that use user data are always sent to the origin by default. This may add latency to requests if the user is closer to a different replica.

You can change this behavior by adding a ?region=closest parameter to your request. Please note that this may lead to inconsistencies for users; if you request user data immediately after writing it, the write request will go to the source location, whereas the read request may target a different location. Updating user data in other regions takes 1 to 60 seconds.