Data subject requests

The privacy request portal gives visitors a way to submit a request against a specific banner. CookieBeam collects the request, confirms control of the email address it was submitted with, records a deadline, and notifies your team. Deciding the outcome and responding to the requester is your work — the product tracks the request; it does not fulfil it.

The portal is a plan-gated feature and must be enabled per banner before it will answer at all.

The submission flow

1. The visitor submits a request naming a request type, an email address, and optionally a name and a message.
2. The portal is resolved and authorized. The banner must exist and be active, the portal must be enabled, and the request must come either from the CookieBeam application itself, with a valid embed secret, or from a domain authorized for that banner. A request type that is not enabled for the portal is rejected.
3. A verification code is emailed. Nothing is created yet — the submission is held, not recorded as a request. The code is stored first and the email is sent without blocking the response, so a send failure is logged but still returns the same "pending verification" result to the requester. A visitor who never receives the email sees success and hears nothing further, and no request exists for your team to action.
4. The visitor enters the code. On success the held submission becomes a request, the clock starts, and your team is notified.

Submission returns the same success response whether or not a hidden honeypot field was filled, so an automated submission cannot tell from the response that it was ignored.

Rate limits

The per-email verification limit exists because a per-IP limit alone does not stop a distributed attempt at guessing codes.

What the email challenge establishes

The code is six digits, generated with a cryptographic random source. Only its SHA-256 hash is stored; the code itself exists in the email and nowhere else. It expires 24 hours after issue, and it is claimed atomically — a single database update marks it verified only if it was still unverified and unexpired, so two simultaneous attempts cannot both create a request.

State this precisely when you document your own process:

• The challenge establishes that whoever submitted the request controls that email inbox, at that time.
• It does not establish who that person is, that they are the data subject whose records are involved, or that any records in your system belong to them.

Identity verification proportionate to the request is a decision you make. If a request concerns sensitive data or a high-risk action, the email challenge is a starting point, not a conclusion — and you may need to seek further verification before acting.

Request types

Eight request types exist:

access, deletion, rectification, portability, object, do_not_sell, anonymization, opt_out_sale

Each portal can be configured to offer a subset; if that configuration is missing or empty, all eight are offered. On top of that, CookieBeam narrows the list by the visitor's detected region:

Region is resolved from edge geo headers. Because CA means both Canada and California, the resolver checks the US state before the country so that a Canadian visitor is not offered California-specific rights.

This narrowing is presentation only. It decides which options the portal page offers a visitor; it is not enforced when a request is submitted. Submission authorizes the request type against the portal's configured allow-list alone, with no regional check, so a request type that the region table does not list for a visitor's location will still be accepted if the portal offers it. Treat the table as guidance about what visitors are shown, and the portal's allow-list as the actual control. Region does have one enforced effect: it selects the deadline policy below.

This regional narrowing is not the same list as the regional banner defaults in Regional frameworks. A regime can ship banner defaults without appearing in the table above; visitors there receive the fallback set, or whatever the portal is configured to offer.

Deadlines

When a request is verified, CookieBeam captures a deadline and stores it on the request:

Three points about that clock, all of which matter if you report on it:

• It starts at verification, not submission. An unverified submission has no deadline because it is not yet a request.
• The 30-day figure is an operational target CookieBeam computes — it is labelled as such in the code. It is not a statement of your statutory deadline, which depends on your jurisdiction, the request type, and whether an extension applies. Where your obligation is shorter than the tracked window, the tracked window will not warn you in time.
• An unknown location gets the shorter window, so missing geo data never quietly lengthens a deadline.

A dashboard summary reports open requests, overdue requests, those due within the next seven days, and those that were resolved after their deadline. Requests move between pending, in progress, completed and denied; a completed or denied request can be reopened to in progress, which is why the summary counts late resolutions rather than assuming a closed request was on time.

Notifications

When a request is created, CookieBeam emails the team's owners and administrators and dispatches a dsar.request_submitted webhook carrying the request ID, banner, request type, requester, status, submission time, deadline and policy. Both are dispatched without blocking the requester's response, and a failure of either is logged rather than surfaced to the requester — so treat the dashboard as the source of truth for what is outstanding, not your inbox.