Collecting Feedback

Feedback is collected by the Roast widget, which you embed on your own site. It appears as a floating launcher button (labelled "Feedback" with a flame icon) pinned to one of four corners — bottom-right, bottom-left, top-right or top-left, depending on the widget's configured position.

When a visitor clicks the launcher (or the widget auto-opens via a trigger), a panel opens on the mode-select screen asking "How are you feeling about us?". From there the visitor chooses Praise or Roast, fills in the relevant form, optionally records a video, and submits. A celebratory success screen confirms receipt.

Every submission is posted to the public endpoint POST /api/submissions. This is an unauthenticated endpoint — end users do not need a Roast account or any login. The widget knows which form it belongs to via a form ID baked into the embed.

The widget supports two feedback types: praise and roast. Praise is always available. The Roast button only appears on the mode-select screen when the form's roastModeEnabled feature is switched on; if it is off, visitors can only leave praise.

Praise mode ("Share Your Love") is built for positive feedback and testimonials. It asks for a 1–5 star rating, a written comment, and optional attribution details (name, email, job title, company) hidden behind an "Add your details" expander. If the visitor sets the rating to 3 stars or below, the form gently suggests switching to Roast mode instead.

Roast mode ("Roast Us") is built for critical feedback. It centres on a heat-level slider and a free-text box, with contextual prompts that change based on the page URL (pricing, checkout/payment, signup/register pages get tailored prompts, otherwise a default set is used). Owners can override these with custom prompts in the form settings. Roast mode also offers a tick-box "I'd like a response when this is fixed" which reveals an email field.

The two modes also differ in their consent model (see the consent and privacy section). Crucially, roasts are treated as private by default — the roast form always sends consentMarketing as false, regardless of what the visitor does.

Heat level captures how strongly a user feels about a problem. It is set with an interactive slider (drag, tap quick-select emoji buttons, or — on the compact variant — a range input). There are five levels, lowest to highest: Lukewarm ("Mild annoyance"), Warm ("Getting frustrated"), Hot ("Pretty annoyed"), Fire ("Major issue") and Nuclear ("Absolute disaster"). The slider defaults to Hot.

Each level has its own emoji, colour and label, and the form background tint shifts as the level changes. The Nuclear level adds a pulsing animation and a red border on the text box. On mobile the slider gives light haptic feedback as you move between levels.

The chosen heat level is sent with the submission and stored against it. The server validates it against the fixed set (lukewarm, warm, hot, fire, nuclear) and rejects anything else. Heat level applies to roasts only; praise submissions carry a star rating instead.

A submission can be text-based or video-based. The media type stored is determined server-side: if a video file is attached the submission is recorded as "video", otherwise "text". The server requires at least one of content or video to be present — an empty submission is rejected.

For text, the visitor types into the comment box (praise) or the roast text box. Content is capped at 10,000 characters server-side.

For video, clicking "Record a video" (shown only when the form's videoEnabled feature is on) opens the in-browser recorder. Visitors can choose Camera Only, or — on desktop browsers that support it — Screen + Face (picture-in-picture), which is recommended for roasts because it lets them point at exactly what is wrong. Screen + Face is hidden on mobile. Recording runs through a 3-2-1 countdown, can be paused/resumed, and is capped at 120 seconds (a warning shows in the final 20%). During screen recording the user can pause to draw annotations on the screen. After stopping, they get a preview with Re-record / Play / Use This, and must tick a consent box before submitting. A JPEG thumbnail is auto-generated from an early frame.

Videos are recorded as WebM (VP9). When submitted through the standard widget flow they are sent as part of the same multipart POST to /api/submissions, which accepts files up to 100MB. The server validates both the file extension (webm, mp4, mov, avi, mkv) and the MIME type (video/webm, video/mp4 or audio/webm) and uploads the file plus thumbnail to the roast-videos storage bucket, storing the resulting public URLs on the submission.

The direct submission endpoint caps videos at 100MB. For larger files there is a separate resumable upload service implementing the tus.io protocol, which uploads the file in chunks and can resume after interruptions. This path supports files up to 500MB.

Unlike the public submission endpoint, the TUS upload endpoints (POST /api/uploads/tus to create an upload, then PATCH/HEAD/DELETE on /api/uploads/tus/[uploadId]) require an authenticated Roast user — every request checks the session and a chunk upload is rejected unless the upload belongs to the calling user. Completed files are assembled and stored in the roast-feedback-media bucket under the user's ID.

Because of the auth requirement, the TUS path is for signed-in dashboard/app contexts rather than anonymous end-user widget submissions, which use the 100MB direct upload.

Display consent is mandatory. Both forms (and the video recorder's preview step) require the visitor to tick a box agreeing that the feedback is recorded/stored before they can submit, and the server rejects any submission where display consent is not true.

Marketing consent is separate and optional. In Praise mode the visitor can additionally tick "I allow this testimonial to be displayed publicly for marketing purposes". In Roast mode this option does not exist — roasts always submit with marketing consent set to false and the form explicitly tells the user their roast is private and won't be shared publicly.

Both consent flags are stored on the submission, so you have an auditable record of what each user agreed to. Use the marketing-consent flag to decide which praise can be published publicly.

On a successful POST /api/submissions the server creates a row in roast_submissions linked to the form, with status set to "pending". Stored fields include: feedback type (praise/roast); media type (text or video); the text content; the video URL and thumbnail URL (if a video was uploaded); heat level (roasts) or rating 1–5 (praise); author name, email, job title and company (where provided); the page URL the feedback came from; the visitor's user-agent; and the two consent flags (display and marketing).

The server validates inputs before storing: type must be praise or roast; rating must be 1–5; email must look valid; author fields are capped at 200 characters; the page URL is capped at 2048 characters and must be a valid http(s) URL.

Newly created submissions start in the "pending" state, ready for review in the dashboard. Creating a submission also fires off your configured integrations (for example Slack, Discord, webhooks or issue trackers) in the background — this dispatch never blocks or fails the visitor's submission.