Feedback API
Send a rating or a comment to a single JSON endpoint from Swift, Python, a server job, a CLI, or curl. The report lands in the same inbox as your widget feedback, clusters with it, and can become a GitHub PR you review and merge.
Most feedback tools ship a JavaScript widget, which is useless the moment the feedback is not in a browser. A native iOS app, an Android app, a desktop client, a backend job, a CLI: none of them can mount a script tag, so the feedback never gets collected.
A widget assumes a DOM. Your native app does not have one, your server-side worker does not have one, and your CLI tool does not have one, so a tool that only ships a widget leaves every non-browser surface dark. The workarounds are worse than nothing: a support email address nobody reads, a Google Form linked from a settings screen, or a custom backend you build and maintain yourself to receive reports and store them somewhere. Meanwhile the feedback that does come in through the widget lives in one system and the feedback from your app lives in another, so you never see that the same bug is being reported on web and on iOS. What you want is a plain endpoint: one HTTP POST, a JSON body, no SDK to vendor and no platform you have to wait for support on, that drops a report into the same place as the rest of your feedback.
How it works
Disclosure: I build Usero, so weigh that. The API is the same endpoint the widget posts to, exposed for direct calls: POST https://usero.io/api/feedback with a JSON body. It sends CORS Access-Control-Allow-Origin: *, so you can call it from a browser, a mobile app, a desktop app, or a server. There is no API key and no auth header; the clientId in the body identifies your project, and it is safe to ship in client code because it only grants the ability to submit feedback to that project. A submission needs the clientId plus at least one of a rating (1 to 4) or a non-empty comment. Everything else is optional: userEmail to reply and group by person, pageUrl and pageTitle for context, environment if you separate staging from production, and a metadata object (up to 10KB) for app version, OS, and build number, so native reports arrive with the context you need to reproduce them. A success returns the new feedbackId. From there it is feedback like any other: it clusters with your widget, Slack, form, and GitHub feedback, and a clustered item can open a GitHub pull request with a first pass at the fix. You review the diff and merge it yourself. Nothing auto-merges.
POST a JSON body to https://usero.io/api/feedback from Swift, Python, Node, Go, a shell script, or a browser. CORS is open, so there is no origin to whitelist for a normal client, and no SDK to vendor for a language Usero does not ship one for.
The clientId in the body identifies your project. There is no secret API key and no auth header to rotate or leak, because the endpoint only accepts feedback submissions for that project. You can ship the clientId in a mobile app or a public client without exposing anything you would not want public.
Attach a metadata object (up to 10KB serialized) with app version, OS version, build number, or feature flags. For a native app, where there is no URL or user agent to read, this is how a report arrives with the state an engineer needs instead of just "it broke".
A report sent through the API is feedback like any other in Usero, so it clusters with your widget, Slack, and GitHub feedback. From a clustered item you click Create PR and Usero opens a pull request with a first pass at the fix, linked back to the report. You review and merge.
The honest objection
The endpoint accepts feedback submissions for the clientId in the body and nothing else, so the worst an exposed clientId allows is someone submitting feedback to your project, the same thing your widget does. If you want to lock it down, set a domain allowlist in Settings and requests from other origins get a 403; new clients have no allowlist so everything is accepted by default. For server-side calls where you control the caller, the allowlist plus your own rate limiting is enough. If you need authenticated, per-user write access to arbitrary data, this endpoint is the wrong tool, it is built for one job: accepting a feedback report.
FAQ
POST a JSON body to https://usero.io/api/feedback with your clientId and at least a rating (1 to 4) or a non-empty comment. It is the same endpoint the widget uses, callable from Swift, Python, a server, a CLI, or curl. No SDK and no API key are required.
No. The clientId in the request body identifies your project. There is no API key and no auth header. The clientId is safe to ship in client code because the endpoint only accepts feedback submissions for that project.
clientId is always required, plus at least one of a rating (integer 1 to 4) or a non-empty comment. Optional fields include userEmail, pageUrl, pageTitle, referrer, environment, screenshots, a metadata object up to 10KB, sessionReplayId, and replayOffsetMs.
Yes. Put them in the metadata object (up to 10KB serialized): app version, OS version, build number, or feature flags. For a native app, where there is no URL or user agent to read automatically, metadata is how each report arrives with the context to reproduce it.
Yes. An API submission is feedback like any other in Usero, so it clusters with your widget, Slack, form, and GitHub feedback. From a clustered item you click Create PR and Usero opens a GitHub pull request with a first pass at the fix. You review the diff and merge it yourself. There is no auto-merge path.
Free tier. No credit card. Two-minute install. The AI opens the PR, you merge it.