Playground
The Playground runs a real Profile API read from inside the app, so you can confirm a Store is serving what you expect before you write any integration code.
Running a read
- Navigate to Personalize → Profile → Playground.
- Pick the Store you want to read from.
- Enter an id and run the read.
The panel shows the response exactly as the API returned it, and offers the same request as a copyable curl command so you can move straight from a working read to working code.
Stores are serve-by-key, so there is no way to list the ids in a Store — the Playground cannot offer you a picker of real ids. It does remember the ids you have already tried in this session and suggests them back to you, so use an id you know exists in the source model.
Two modes
| Mode | How it authenticates | When to use it |
|---|---|---|
| Debug | Your signed-in session, through Zeotap — no key needed | Confirming a Store is serving what you expect. Requires the stores.read permission |
| Live | A serving key (svk_…) you supply, calling the Profile API directly | Confirming the exact call your application will make, under the credential it will use |
Unlike the Membership Playground, the two modes return the same shape here — an Entry is an Entry. What differs is the credential and who answers: Debug is proxied through the app, Live goes to the Profile API itself. So a read that works in Debug and fails in Live is telling you something about your key, not about your data.
The Profile API takes a serving key (svk_…) carrying serve:profile. Platform keys (sk_, rk_) are refused on their class, before scopes are even considered — adding read:store to an sk_ key will not make it work. Generate a serving key from the panel itself if you do not have one.
Each result in the history is badged with the mode that produced it, because two reads under different credentials are not comparable without knowing which was which.
What a 404 means here
A 404 in the Playground means the same thing it means in production: nothing has been published for that id. Common causes, in the order worth checking:
- The feed has not run yet — check the Store’s Refreshes tab.
- The id you entered is not the feed’s Primary key value for that row.
- The row left the source model and the feed’s On removed source row setting deleted the Entry.
A 403 is a different thing entirely, and only happens in Debug: your role does not carry the stores.read permission the proxied read needs. Switch to Live with a serving key — the Profile API does not consult your workspace role.
Next Steps
- Profile API — the endpoint reference, for when the read works and you are ready to integrate.
- Stores — feeds, schedules, and the Refreshes tab.