Customer privacy topics

How an app learns that a merchant asked for a customer's data or for their personal data to be erased, what the payload carries, and what your app must do.

A shopper can ask a store for the data it holds about them, or ask the store to erase it. The merchant files that request in the Queek dashboard, and Queek tells every installed app that declares the matching topic, so the app can find and erase its own copy. Queek erases its own copy at the same time.

The short version

Declare customers/data_request and customers/redact in your manifest. On each one: verify the signature, dedupe on data.id, answer 2xx, then act on the customer id and order ids in data. On customers/redact, erase everything your app holds about that customer. When a store is deleted, the app/uninstalled handoff with reason: "store_deleted" means the same for the whole store.

The two topics

Topic	Fires when
`customers/data_request`	The merchant asked, on a shopper's behalf, for the data held about a customer. Sent at once.
`customers/redact`	The merchant asked for a customer's personal data to be erased, and the cancellation window has passed.

Both are sent to every active installation whose manifest declares the topic. They are duties, not permissions: you need no scope, the merchant sees no approval line for them, and they are sent even if the store has switched customer topics off. You do not need to be granted them at install time; add them to the manifest, deploy a new version, and installs that already have a webhook endpoint start receiving them.

queek.app.toml

[webhooks]
topics = ["customers/data_request", "customers/redact"]
url = "https://my-app.example.com/webhooks"

The payload

The body is the usual webhook envelope. data carries ids only and never a name, email or phone:

{
  "id": "9f0f7a0e-3c1e-4c7b-9a4b-2d8f1e6c0a11",
  "topic": "customers/redact",
  "api_version": "v1",
  "created_at": "2026-10-28T03:45:12+01:00",
  "data": {
    "id": 1043,
    "customer": { "id": 7731 },
    "requested_at": "2026-10-18T10:42:07+01:00",
    "orders": [48213, 48390],
    "orders_truncated": false
  }
}

Field	Notes
`data.id`	The privacy request's id. Dedupe on it. A retry, or a resend after a Queek-side crash, carries the same `data.id`.
`data.customer.id`	The customer's id, the same id the `customers/*` events and `GET /customers/{customer}` use.
`data.requested_at`	When the merchant filed the request.
`data.orders`	The customer's order ids at this store, in id order, up to a cap.
`data.orders_truncated`	`true` when the customer has more orders than the list carries.

Because the payload has no contact details, an app that stored data keyed only by something it collected itself (an email typed into your own form, for example) cannot be addressed by id. Keep the Queek customer id beside anything you store about a customer.

What your app must do

Verify the signature against the raw body, as for every webhook.
Dedupe on data.id, and answer 2xx promptly. Do the work after the acknowledgement.
On customers/data_request, collect what you hold about that customer and give it to the merchant by your own means. Queek does not collect it for you.
On customers/redact, erase or anonymise everything you hold about that customer, including anything keyed to the order ids in the payload. Finish within 30 days of receiving it. Queek does not track completion.
If the law obliges you to keep some of it, keep only that, and say so to the merchant.

Timing

A data request is sent as soon as the merchant files it.

An erasure is pending first, so a mistaken click can be cancelled. It becomes due after 10 days. If the customer's most recent order at the store is less than 180 days old, it is held until 180 days after that order. When it falls due, Queek sends customers/redact and then anonymises its own copy of that customer for that store. The dashboard shows the merchant the due date up front.

Only the store that filed the request is involved. The same person at another store is not touched, and that store's apps are not told.

Delivery and limits

Delivery follows the standard retry schedule: up to 8 attempts over about 3 hours 42 minutes. An endpoint that fails for 24 hours is disabled, and later notices stop until it is enabled again. The merchant can replay a retained delivery for 7 days. Queek does not wait for your app to answer.
Delivery is at-least-once and unordered. Dedupe on data.id.
An installation can only receive these topics if it has a webhook endpoint, which exists when the manifest had a webhook URL and at least one topic when the app was installed. An install made without one must be reinstalled first.
Only the merchant can file these requests. An app cannot, and a shopper deleting their account in the Queek mobile app does not send anything to the stores they bought from.
customers/delete is a different event: the customer was removed from the store's directory. It is not an erasure, and data held elsewhere about that person is not deleted.

When a store is deleted

Deleting a whole store ends every installation first. Each app receives the signed app/uninstalled handoff with data.reason set to "store_deleted", once per installation, after the store's grace period. That is the shop-level erasure signal: delete the installation and every copy of the store's customer data. Queek anonymises every customer in the store itself, so no per-customer customers/redact is sent in that case. See Data and uninstall.

What Queek keeps

When an erasure runs, Queek anonymises the customer's profile, removes their links, addresses, notes and pins from their orders, and deletes their carts, wishlist, campaign and segment memberships and the store's saved address book. It keeps:

the financial order record (amounts, dates, status), with the customer unlinked, for the retention period;
records tied to the shopper's global Queek account, which is shared across stores (reviews, ratings, comments, bookmarks, assistant threads);
messaging-inbox transcripts held by the messaging gateway.