Use cases

Bug reports with annotated screenshots

The bug report that says "the invoice looks wrong" is missing the one thing support needs: the screen. Asking users to screenshot, crop, annotate and attach it themselves loses most of them at step one — and the reports that do arrive carry no ticket id, no user, no context your tooling can route on.

The capture matches what they saw

Computed-style capture means their dark mode, their data and their half-scrolled table come through as rendered — which for a bug report is the entire point.

The markup is where the information is

Arrows, boxes, highlighter, text and a caption box — the caption is usually the sentence that explains what they were actually complaining about. Redaction genuinely destroys the pixels underneath, so a screenshot of a billing page can be shared safely.

It arrives as data, not an attachment

Attach params at the call site — user id, ticket id, build number — and the webhook delivers file URLs plus that context, signed. Routing a report to the right queue is a lookup, not an email parse.

Questions people ask

Does anything upload before the user confirms?
No. Capture, annotation and redaction all happen in the browser; nothing leaves the page until the user hits Send, and redacted pixels are destroyed before the file is even encoded.
How does the report reach our tracker?
Your endpoint receives a signed webhook with the file URLs, the caption and your params. From there it is one handler to create the ticket in whatever you use.