Data Subject Requests · Advanced

Using the API.

An optional, developer-focused way to wire Superset directly into your own systems. You don't need it to run DSRs end to end.

Everything in Decide what to automate works without writing any code, and the API Call step there already pushes each qualifying request to your endpoint the moment it arrives. That covers most teams.

This page is for the deeper cases: when your engineering team wants Superset wired more directly into your own systems. It's an optional, developer-focused path, not a required part of getting set up. You can run DSRs end to end in Superset without any of it.

Every endpoint is authenticated with an API key passed as a bearer token: Authorization: Bearer <token>. To request a key, ping your Superset contact or email [email protected]. Full endpoint, field, and example reference lives in the developer docs at docs.trustsuperset.com.

There are two directions:

Superset pushes to you using the API Call step, the moment a qualifying request arrives. This is the usual way to feed a downstream suppression or deletion list.
You pull from Superset using the REST endpoints below, on your own schedule.

Pull request data

List your organization's requests, filtered and paginated. received_after and received_before accept a Unix epoch or an ISO 8601 date; use after_id for stable keyset pagination (start at 0 and follow pagination.next_cursor until it's null) rather than offset, which can shift as new requests arrive.

curl --location -g 'https://api.trustsuperset.com/dsr/?status=completed&received_after=2026-01-01&limit=100&after_id=0' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer <token>'

Fetch a single request by ID with GET https://api.trustsuperset.com/dsr/:dsr_id/.

What a request holds

A data subject can present more than one identity: several email addresses, several phone numbers, a current home and a previous one. So each kind appears twice inside a request's data object — as a primary_* scalar and as an all-inclusive array, with the primary first — and you can read whichever suits your system without losing the others.

"data": {
  "first_name": "Dana",
  "last_name": "Rivers",
  "primary_email": "[email protected]",
  "emails": ["[email protected]", "[email protected]"],
  "primary_phone": "+1 555 123 4567",
  "phones": ["+1 555 123 4567"],
  "primary_address_1": "40 Corsi Road",
  "primary_city": "Bloomfield",
  "primary_state": "NJ",
  "primary_zip_code": "07003",
  "primary_country": "United States",
  "primary_address": {
    "address_1": "40 Corsi Road", "address_2": "", "city": "Bloomfield",
    "state": "NJ", "region": "", "zip_code": "07003", "postal_code": "",
    "country": "United States"
  },
  "addresses": [ /* every address held, current first */ ],
  "maids": []
}

Field	Type	Notes
`primary_email`	string	Same as `emails[0]`.
`emails`	array of string	Every address held, primary first.
`primary_phone`	string	Same as `phones[0]`.
`phones`	array of string	Every number held, primary first.
`primary_address_1`, `primary_address_2`, `primary_city`, `primary_state`, `primary_region`, `primary_zip_code`, `primary_postal_code`, `primary_country`	string	The current address, component by component.
`primary_address`	object	Those same eight components as one object. Same as `addresses[0]`.
`addresses`	array of object	Every address held, current first. Each entry carries all eight components, blank string for anything we don't hold.
`maids`	array of string	Mobile advertising IDs (Apple IDFA, Google GAID/AAID).

first_name, middle_name, last_name, full_name, business_email, date_of_birth, linkedin_url, requester_type, applicable_law, and authorized_agent_name are plain strings.

Treat data as a blob It's schemaless, and its key set varies from request to request — what a webform collects isn't what an agent's email yields. Read the keys you need, and treat any key you don't recognize as informational rather than an error.

Create requests

Submit one or more requests as a JSON array, for example to forward DSRs you receive through another channel. Valid request_type values are erasure, rectification, restriction, portability, automated, and optout.

curl --location -g 'https://api.trustsuperset.com/dsr/new/' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <token>' \
  --data-raw '[
    {
      "request_type": "erasure",
      "email": "[email protected]",
      "first_name": "Jane",
      "last_name": "Doe",
      "country": "US",
      "region": "CA",
      "origin": "API"
    }
  ]'

The same names the request shape above uses are accepted on the way in, so you can send everything you hold for a data subject in one request: emails, phones, addresses, primary_address, maids, and any of the primary_* scalars. Sending emails on its own satisfies the required email field — the first entry becomes the primary. The original input names keep working exactly as before, so an integration you already have needs no change.

Forwarded by an authorized agent? When a request comes through an agent service (Incogni, DeleteMe, Optery, and the like), the agent's address is only a relay, not the data subject. Set email to the data subject's primary address, or send emails with every address you hold for them. Create one request per data subject, not one per email address, and keep the agent's address in metadata if you need it for audit or reply routing. Any keys beyond the reserved ones are stored on the request and returned by the API.

Update status in bulk

Mark requests complete (or move them to another status) in one call. Set execute_automation to true to run the configured automation as part of the update. When a request becomes completed, Superset sets its completed_at automatically.

curl --location -g 'https://api.trustsuperset.com/dsr/status-update/' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <token>' \
  --data '{
    "dsr_ids": [123, 124],
    "status": "completed",
    "execute_automation": true
  }'

Delete requests

Permanently delete one or more requests by ID. Deletion is all-or-nothing: if any ID isn't found for your organization, nothing is deleted. This one is irreversible, so use it deliberately.

curl --location 'https://api.trustsuperset.com/dsr/delete/' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <token>' \
  --data '{ "dsr_ids": [123, 124] }'

Ping your Superset contact when you have a specific use case and we'll set up a call.