In-app Feedback

Collect feedback from your own app, CLI, or AI agent

In-app feedback lets the people who use your product send feedback straight into Modem. You create a feedback channel for each place feedback comes from, put its token in that app, and every submission lands as a conversation that groups into topics, links to people and companies, and can start an automation.

How it works

A feedback channel is one place feedback comes from: your web app, a CLI, your support assistant. Each channel has its own token, its own list of allowed browser origins, and its own on/off switch, so you can rotate or disable one without touching the others.

Clients send feedback to https://ingest.modem.dev/feedback with the token as a bearer header. Modem accepts the submission, stores any screenshots, and records it as a feedback_submission conversation in the channel. From there it is processed like every other source.

There are three ways to send feedback, and one channel can receive from all of them:

Prerequisites

• Owner or admin role in your Modem organization, to create channels and manage tokens. Any member can view the channels page.
• A place to put the token: a public environment variable for a web app, a config file for a CLI, or an agent’s MCP configuration.

Setup

The fastest path is to hand the work to your coding agent. Modem ships an install-feedback skill on its MCP server that creates the channel, stores the token, adds the UI, and sends a test item.

To set things up by hand instead, create a channel in Settings → Feedback Channels, then install the widget or call the endpoint with the token.

Feedback channels

Settings → Feedback Channels lists every channel with its origins, tokens, creation date, and switch. Admins create and manage channels; members can view the list.

Creating a channel

Click Create Channel and give it a name of up to 100 characters. Optionally add allowed origins, one per line. Modem shows the full token once, in the dialog that follows. Copy it there; the table only ever shows the first few characters again.

Every channel also gets its own entry in Modem’s channel list, so you can scope an automation or a product to one channel.

Allowed origins

Allowed origins protect a token that ships in a browser bundle. When the list has entries, Modem accepts a submission only if the request’s Origin header matches one of them exactly. Enter bare origins such as https://app.example.com or http://localhost:3000, up to 20 per channel. Wildcards, paths, and query strings are not allowed.

Requests that carry no Origin header, such as a backend, a CLI, or an agent, always pass this check. A channel with an empty list accepts any origin.

Rotating and revoking tokens

From a channel’s menu you can rotate or revoke its token:

• Rotate issues a new token and keeps the old one working for 24 hours, so you can roll a deployment without a gap.
• Revoke stops a token immediately. This cannot be undone.
• Disable a channel with its switch to pause every token on it at once. Re-enable it to resume.

Channels cannot be deleted. Disable one you no longer use. Historical feedback stays in Modem either way.

Installing with a coding agent

The install-feedback skill does every step itself. It reads your project to learn the framework and where public environment variables live, asks one question about placement if you have not said where feedback should go, then calls create_feedback_channel with your app’s production and local origins.

The token goes into your project’s public environment variable, NEXT_PUBLIC_MODEM_FEEDBACK_TOKEN for Next.js or VITE_MODEM_FEEDBACK_TOKEN for Vite, and never into chat, logs, or a tracked file. For a web app with shadcn/ui the skill installs the widget. For anything else it wires a request to the endpoint, and for an app with its own AI agent it adds the feedback MCP server to that agent.

Creating a channel needs an organization admin and the agent:invoke scope. If your token lacks either, the skill still builds the UI and tells you to create the channel in Settings → Feedback Channels and paste the token yourself.

The feedback widget

The widget is a shadcn/ui registry item. Install it into any React project that uses shadcn/ui:

npx shadcn@latest add https://app.modem.dev/r/feedback.json

It adds four files to your project, feedback-trigger.tsx, feedback-error-form.tsx, a modem-feedback client library, and a use-feedback-form hook, along with the button, dialog, input, label, and textarea primitives. The code is yours to restyle.

FeedbackTrigger renders a Feedback button that opens the dialog. Pass the token and, when you know who is signed in, the viewer:

<FeedbackTrigger feedbackToken={process.env.NEXT_PUBLIC_MODEM_FEEDBACK_TOKEN} viewer={{ name: user.name, email: user.email }} />

With a viewer email the dialog hides the name and email fields and sends the viewer’s details. Without one it asks for an optional name and email. Either way the reporter can attach up to two screenshots of 5 MB each in PNG, JPEG, GIF, or WebP, and write a message of up to 4,096 characters. The page URL goes along automatically. On success the dialog thanks the reporter and closes itself after two seconds. If the request fails, the draft stays and the reporter can resend.

FeedbackErrorForm is the crash-report variant for your error boundary. It sends the error’s name and message as context and, if you pass an error-tracking eventId, links the report to that event.

If your app sets a Content Security Policy, add https://ingest.modem.dev to connect-src.

Feedback from your own AI agent

If your product has an AI assistant, give it a way to report problems. The hosted feedback MCP server at https://mcp.modem.dev/feedback exposes one tool, submit_feedback, authenticated with your feedback token. Add it to the assistant’s MCP configuration:

{
    "url": "https://mcp.modem.dev/feedback",
    "headers": { "Authorization": "Bearer <feedback token>" }
}

The tool’s instructions tell the agent to offer a report when one of your app’s tools fails, returns something it cannot act on, or gives an unclear error, and when the user voices frustration or asks for something the app cannot do. It sends only when the user asks to or agrees, and it says what it will send.

Reports carry a category tag: agent_friction for the agent’s own report of a failing tool, or user_feedback for the user’s words. When your runtime knows who is signed in, set the X-Modem-App-User header on the MCP connection and the tool stops asking for a name or email. See the feedback MCP server reference for the headers and tool schema.

What gets captured

Each submission becomes one feedback_submission conversation in its channel, with the message as its only entry. Screenshots are stored and attached to the message, and text in them is extracted so the agent can read it.

The name and email a reporter types are recorded as claimed contact details on the submission. Modem uses the email to match an existing person at low confidence. It does not treat a typed email as proof of identity, so a claimed match alone does not show that person as the author in topic views. Reports that arrive with X-Modem-App-User are recorded the same way, keyed by your app’s own user ID.

Tags, trace ID, release, and environment travel with the submission and are passed to automations that the submission triggers.

Automations

Every submission fires the Feedback Created event, so a trigger automation can act on it immediately. Pick feedback is submitted as the trigger and, if you want, limit it to one channel.

The agent receives the message, the reporter’s contact details when given, the channel, and the tags. A prompt like this posts every new item to Slack with the topic it belongs to:

The same event fires for user feedback captured through Sentry and posts captured through Canny, with a provider field that says which.

Analyzing feedback

Ask the Modem Agent about feedback like any other source:

Troubleshooting

Related