Worked personalization samples
The endpoint list below documents every operation’s parameters; this overlay walks a slot the way a tenant’s frontend actually uses it: list the slots → read one variant → update it → handle the duplicate-variant conflict. Success envelopes are{ data, meta }, error envelopes
{ error, meta } — see How to read a worked
sample. The platform accepts both a sandbox
(dv_test_sk_*) key and a live key; the write paths (create/update/delete)
require owner or admin, while the list/get/preview paths are just read.
Every response carries meta.request_id. Quote it when you report a slot
serving the wrong variant — support traces the routing end-to-end from
the request id and the recompute tick.
1. List personalization slots
GET /api/v1/personalization/slots returns the slot variants configured
for this tenant, ordered by id and paginated with a cursor. Filter by
slot to inspect a single placement or by segment_label to see what
one audience is served. An unknown segment label is treated as no filter,
so a renamed segment still returns a row.
200
2. Read one variant
GET /api/v1/personalization/slots/{id} returns a single slot variant:
content, CTA link and label, target segment, variant name, priority,
active flag, and metadata. Use it to hydrate the slot edit form before a
PATCH.
3. Create a slot variant
POST /api/v1/personalization/slots defines the markup the SDK renders
into a slot for one audience. The variant is keyed on slot +
segment_label + variant; only one active variant may exist per
triple, so a second POST for the same key returns 409 (taken up under
Errors below). Omit segment_label to define the default content
every visitor sees when no segment-specific variant matches. content
is accepted only when the markup rules pass — scripts, iframes, inline
event handlers and javascript:/data: (non-image) URLs are rejected
with 422 because the SDK injects the markup into your page.
201
id is the
handle the GET, PATCH, and DELETE paths below take.
4. Update a variant’s copy
PATCH /api/v1/personalization/slots/{id} is the in-place update the
sdk/personalize endpoint draws from — send only the fields you are
changing. An omitted field keeps its stored value, so a copy edit never
silently re-ranks a variant or re-enables a stopped one. Set
active: false to stop serving a variant without deleting the row.
200
contentis re-checked on update against the same HTML rules as create — script execution, iframes, and event handlers are rejected.priority0–100 ranks variants inside one(slot, segment_label, variant)tuple; an update that leavespriorityuntouched never re-materializes it to the schema default.
5. Errors
Errors follow the{ error, meta } envelope. Two failures every admin
hits:
409 — duplicate variant. The triple (slot, segment_label, variant)
must be unique. Creators hitting this should PATCH the existing row
instead of POSTing a new one.
422 — rejected markup. The sanitizer rejected the content, or the
update body was empty:
422