Collecting feedback is the easy half. The half that decides whether anything gets fixed is where the report ends up — and a report in a tool your engineers do not open every morning is a report that ages.
Filing directly into GitHub Issues puts it in the queue that already governs the work.
The credential
A fine-grained personal access token scoped to a single repository with the Issues permission set to Read and write. That token cannot read your source, cannot push code, and cannot reach any other repository.
It is encrypted with AES-256-GCM before storage, and the column holding it is not selectable through the data API by any client role.
What lands in the repository
The title is the reporter's summary prefixed with the feedback type and, where they set one, the severity — "[Bug · S4] Checkout button does nothing". The body carries the description, every custom field under its human label, and a context block with the page URL, page title, viewport, user agent, timestamp, and the reporter's email if they gave one. Your configured labels and assignees are applied on creation.
If the reporter attached a screenshot, the body embeds it as an image with its dimensions. GitHub's API cannot take a binary when it creates an issue, so what goes in is a signed link to a private object rather than an upload; Jira, which can take a real file, gets the file.
Exactly one issue, always
GitHub does not offer an idempotency key on issue creation, so it is enforced locally: a deterministic key per feedback-and-destination pair with a unique index behind it. Concurrent workers race for the insert, one wins, the rest stand down. A retry after a timeout cannot produce a second issue.
When GitHub is down
The visitor still gets a confirmation and the report is still saved — delivery failure is never their problem. The delivery is marked failed with the reason, surfaced on the integration page, and retryable from the report once the cause is fixed.