Privacy & GDPR
How Roast captures respondent consent at submission time, where video and feedback data are stored, and how to delete a submission to satisfy a right-to-erasure request. This page reflects the behaviour actually implemented in the widget and submissions API.
How consent is captured
Every respondent must give consent before a submission can be created. The widget enforces this on the client, and the API rejects any submission where the required consent flag is not set. Two distinct consent signals are recorded against each submission: consent_display (required) and consent_marketing (optional).
The required consent (consent_display) covers recording and storing the feedback. In Praise mode the wording is "I consent to this feedback being recorded and stored." In Roast mode it is "I consent to this roast being recorded for product improvement purposes." For video, the consent line shown before submitting reads "I consent to this video being recorded and displayed" (praise) or the roast variant.
The optional marketing consent (consent_marketing) only appears in Praise mode: "I allow this testimonial to be displayed publicly for marketing purposes." This is the flag your team should check before publishing a testimonial publicly (for example, on a Wall of Love).
Roast-mode submissions are treated as private by design. The Roast form hard-codes consent_marketing to false and tells the respondent "Your roast is private and won't be shared publicly." There is no UI to grant marketing consent for a roast.
The required consent checkbox is marked with an asterisk and the submit button stays disabled until it is ticked (and text content or a video is present).
Video submissions have their own consent checkbox shown in the recorder preview step; the "Use This" button is disabled until it is ticked. This consent is passed through with the recording.
The API independently re-checks consent: if consent_display is not "true"/"1", the POST is rejected with 400 "Consent is required". Client-side ticking alone is never trusted.
Consent values are coerced case-insensitively and accept either "true" or "1". Anything else is treated as no consent.
Roast mode is only offered if the form has roast mode enabled in its settings.
What data is collected per submission
When a submission is created, Roast stores the feedback type (praise/roast), media type (text or video), text content, heat level, star rating, and the page URL the widget was on. It also stores any optional author details the respondent chose to provide.
Author details are always optional from the respondent's side. Praise mode offers name, email, job title and company under an "Add your details (optional, for attribution)" section. Roast mode only collects an email, and only if the respondent ticks "I'd like a response when this is fixed".
Roast also records the respondent's browser user-agent string and the page URL automatically, plus both consent flags. These are stored alongside the submission for audit and context.
Personal data that can identify a respondent (name, email, company, video/voice, IP-adjacent signals like user-agent) is only present when the respondent supplied it or it is captured automatically (user-agent, page URL).
Email is validated for format server-side; author name/title/company are capped at 200 characters and page URL at 2048.
There is no separate respondent account — submitters are anonymous visitors on the customer's site, identified only by what they choose to share.
Where and how videos are stored
Video testimonials and roasts are uploaded to a storage bucket named roast-videos. Direct uploads are limited to 100MB; larger files go through resumable (TUS) upload. Allowed formats are webm, mp4, mov, avi and mkv, and the server validates both the file extension and the MIME type.
Each video is stored under a path namespaced by the form ID with a randomised filename, and an optional JPEG thumbnail is stored alongside it. After upload the server generates a public URL (getPublicUrl) which is saved on the submission as video_url. This means anyone holding the URL can view the file.
Uploads are performed server-side using a service-role client, not the public anon key, so visitors cannot write to the bucket directly. But because the resulting URLs are public, treat video_url as effectively shareable — do not rely on obscurity for confidentiality of video content.
video_url being a public URL is a privacy consideration worth communicating to respondents and reflecting in your own privacy policy.
Text-only submissions have no video and store content directly in the database.
Right to deletion (erasure)
Roast supports the right to be forgotten by permanently deleting a submission and its associated video. Deleting a submission via the API (DELETE /api/submissions/{submissionId}) removes the database row and also removes the video file from the roast-videos bucket.
The deletion is hard, not a soft hide: the submission record is removed with no recovery path inside the product. If the submission had a video, the route derives the storage path from video_url and removes the file from storage using the service-role client before deleting the row.
Video cleanup is treated as best-effort: if removing the file from storage fails, the error is swallowed and the submission row is still deleted. In rare cases this can leave an orphaned video file in storage even though the submission record is gone — worth knowing when you need to certify that all of a respondent's data has actually been erased.
- 1Identify the submission you need to erase (for example, in response to a respondent's erasure request).
- 2Issue a DELETE request to /api/submissions/{submissionId} while signed in to the owning workspace with sufficient permissions.
- 3On success the API returns { success: true }; the submission row and (where present) its video are removed.
- 4If you require certainty that the video file itself is gone, verify the file is no longer present in the roast-videos bucket, because storage cleanup is non-fatal and can silently fail.
Deletion is permanent. There is no undo and no soft-delete/restore.
Gotcha: the DELETE capability exists at the API level but is not wired to a dedicated 'Delete' button in the submissions dashboard in the code reviewed. Owners/admins fulfilling an erasure request may need to call the endpoint directly (or via tooling) rather than expecting a one-click control. Status changes like reject/flag are available in the UI but do NOT delete data.
Rejecting or flagging a submission (PATCH status) only changes its status — it does not remove personal data. Use DELETE for actual erasure.
Who can delete data (permissions)
Deletion requires authentication and the submissions:write permission within the workspace that owns the submission. The request must come from a signed-in user; anonymous or unauthenticated calls are rejected with 401.
Roast resolves the caller's workspace and role, then checks the role against the permission map. Owner, admin and editor roles all hold submissions:write and can therefore delete submissions. The viewer role is read-only and cannot delete (or change status); a viewer attempting deletion receives 403 Forbidden.
The route also verifies that the submission belongs to the caller's workspace before doing anything. A submission whose form is owned by a different workspace returns 403/404, so one workspace can never delete another's data.
Role capabilities for data actions: Owner — full control. Admin — can delete/approve/reject submissions. Editor — can delete/approve/reject submissions. Viewer — read-only, cannot delete.
Members read the owner's submissions; the actual delete is performed server-side via the service-role client only after the ownership and role checks pass.
The same role gate (submissions:write) governs status changes via PATCH, so the people who can moderate are the people who can erase.
Marketing consent vs public display
consent_marketing is the flag that records whether a respondent agreed to have their testimonial shown publicly. It is captured only in Praise mode and is never set for roasts.
Before publishing any testimonial publicly, check that consent_marketing was granted for that submission. The required consent (consent_display) covers storage and internal use only — it is not permission to publish.
Roasts must not be published publicly: the product captures them as private and forces consent_marketing to false.
If a respondent later withdraws marketing consent, there is no toggle to flip consent_marketing after the fact in the reviewed code — withdrawal in practice means deleting the submission or simply not displaying it publicly.
Frequently asked questions
- Is consent mandatory before someone can submit feedback?
- Yes. The required consent_display flag must be ticked. The widget keeps the submit button disabled until it is, and the API rejects any submission without it (HTTP 400 "Consent is required"). Client-side checks are re-validated server-side.
- What's the difference between the two consent checkboxes?
- consent_display (required) covers recording and storing the feedback. consent_marketing (optional, Praise mode only) covers displaying the testimonial publicly for marketing. Check consent_marketing before publishing anything publicly; consent_display alone is not permission to publish.
- Are roasts ever shown publicly?
- No. Roast mode hard-codes consent_marketing to false and tells respondents their roast is private. There is no UI to grant public/marketing consent for a roast.
- How do I action a 'right to be forgotten' request?
- Delete the submission via DELETE /api/submissions/{submissionId}. This permanently removes the database record and attempts to remove the associated video from the roast-videos bucket. Note this is an API-level action; the reviewed dashboard does not expose a dedicated delete button, so you may need to call it directly. Status changes (reject/flag) do not erase data.
- Who is allowed to delete a submission?
- Any signed-in workspace member with the submissions:write permission — Owner, Admin or Editor. Viewers are read-only and get 403 Forbidden. The submission must belong to the caller's own workspace, otherwise it is rejected.
- Can a deleted submission be recovered?
- No. Deletion is permanent with no soft-delete or undo. The row is removed and the video is removed from storage.
- If deletion succeeds, is the video definitely gone from storage?
- Usually, but not guaranteed. The submission row is always deleted, but video file removal from the roast-videos bucket is best-effort: if it fails, the error is ignored and the row is still deleted. For certified erasure, verify the file is no longer in the bucket.
- Are stored videos private?
- No. Uploaded videos are stored with a public URL (getPublicUrl) saved as video_url, so anyone with the link can view the file. Treat video URLs as effectively shareable and reflect this in your privacy policy.
- What personal data does Roast store about a respondent?
- Only what they provide plus a small amount captured automatically: optional name, email, job title and company (Praise) or email (Roast, if they want a reply), any text content or video/thumbnail, the page URL, the browser user-agent, and the two consent flags.