GDPR Requests (Shop)

A customer raises a data request (delete or update their data), lists and views their own requests, revokes a pending one, or deletes the record. The whole surface is gated by an admin setting — when GDPR is disabled in the admin configuration, every call returns an error.

Prerequisites

• A valid storefront key (Setup, Authentication).
• A logged-in customer (Bearer token) — requests are owner-scoped.
• GDPR enabled in the admin configuration. If it is off, every endpoint returns 400 with a "GDPR is disabled" message.

Dependency diagram

Ordered call table

#	Step	Endpoint	Depends on	Note
1	Raise request	POST raise · GraphQL	logged-in customer	Body { type: delete | update, message } → 201 pending
2	List own requests	GET list · GraphQL	logged-in customer	Only yours
3	View request	GET view · GraphQL	one of your requests	404 if not yours
4	Revoke	POST revoke · GraphQL	a pending / processing request	422 if already resolved
5	Delete record	DELETE request · GraphQL	one of your requests	Removes the request record

GraphQL equivalents: gdprRequests / gdprRequest (read) and the createGdprRequest / revokeGdprRequest / deleteGdprRequest mutations. Select result fields on the mutation payloads, not id — see Identifiers.

End-to-end sequence

raise (delete or update) → list → view → revoke while still pending, or delete the record.

Revoke only applies while the request is pending or processing; once the store has resolved it, revoke returns 422 (see Errors).

Customize

Every call below links to its REST endpoint page for concreteness. The sequence is transport-agnostic — the same flow works over GraphQL with the equivalent query or mutation, and each REST page cross-links to its GraphQL twin. Pick whichever transport your client uses; only the request shape changes, never the order of steps.

To change GDPR behavior on the server, see Customization → Shop.