Release notes

What’s new.

Changes worth knowing about, newest first, and what each one means for a setup you already have running.

New template variable names, and every identity in one call

August 11, 2026

We renamed the template variables you use in DSAR automation steps. Nothing you have configured needs to change — we updated every saved automation template for you when the release went out.

The old names still resolve if you type one by hand, so a template you copy in from a doc or restore from your own notes will not silently break. They are no longer offered in the variable picker, and they will be removed in a future release, so move to the new names the next time you edit a template.

Before and after

Old	New
`{{email}}`	`{{primary_email}}`
`{{phone}}`	`{{primary_phone}}`
`{{address_1}}`	`{{primary_address_1}}`
`{{address_2}}`	`{{primary_address_2}}`
`{{city}}`	`{{primary_city}}`
`{{state}}`	`{{primary_state}}`
`{{region}}`	`{{primary_region}}`
`{{zip_code}}`	`{{primary_zip_code}}`
`{{postal_code}}`	`{{primary_postal_code}}`
`{{country}}`	`{{primary_country}}`
`{{maid}}`	`{{maids}}`
`{{additional_emails}}`	`{{emails}}`
`{{additional_addresses}}`	`{{addresses}}`

The last two rows are not pure renames {{additional_emails}} and {{additional_addresses}} meant “the other ones” — every email except the primary, every address except the current one. {{emails}} and {{addresses}} are all-inclusive: the primary email and the current address are in there too. So if your API call body used either of the old names, the payload you receive now also contains the primary email or the current address. Nothing is lost, a value is added — but if you deduplicate on your side, that is the row to read twice.

Why the names changed

A data subject can present more than one identity: several email addresses, several phone numbers, a current home and a previous one. The variables now come in pairs — a primary_* scalar holding the single best value, and an all-inclusive plural array holding everything we have. {{emails}} always starts with {{primary_email}}, {{phones}} with {{primary_phone}}, {{addresses}} with the current address. The old names could not say which they meant, which is the whole reason for the rename.

Full list with types, and how arrays and objects render inside a JSON body: the variable reference.

Multiple phone numbers

Superset used to hold one phone field, so several numbers for one person were packed into it separated by semicolons. There is now a real list. {{phones}} gives you every number, {{primary_phone}} gives you the first. Historical requests work with no backfill on your side — an old packed value is split when it is read — and an extension stays attached to its number, so "555-123-4567, ext 89" is one number rather than two.

One call per request

A request now reaches your endpoint as a single API call carrying every identity we hold for it, instead of one call per email address. One call, one status code, one unambiguous outcome. If your endpoint can only accept a single identifier at a time, we can configure per-identity delivery for your organization — get in touch and we will set it up.

API changes

All additive. No key was removed anywhere, so no integration breaks.

GET /dsr/{dsr_id}/ — the data object now carries the new names alongside the ones it already had.
POST /dsr/new/ — additionally accepts emails, phones, addresses, primary_address, maids, and every primary_* scalar. Sending emails on its own satisfies the required email field: the first entry becomes the primary. The old input names keep working exactly as before.

See Using the API for the shapes.

Your DSR form is untouched Form field ids are deliberately not renamed. Your DSR form still uses email, phone, and address_1. Form fields describe the question you ask a data subject; template variables describe the value we send you. Two vocabularies, two jobs.