Feature requests

A built-in request board, exposed inside your app and at a shareable public roadmap URL. Users submit, vote and comment; you triage status; everyone sees what's shipping.

A different shape

Feature requests doesn't use the four-stage composer the other channels do. It's configured once under Requests → Settings, then you live in two places: the public roadmap (your users) and the triage board (your team).

Configuration

The single configuration form has six sections. Each option below is what you'll see in the dashboard.

Entry

Field	Notes
`enabled`	Master toggle. When off, the SDK board doesn't render and `submitRequest` rejects with `disabled`.
`entryLabel`	The string shown on your in-app entry point (1–60 chars). Default: Feature requests.

Permissions — who can do what

Two segments gate access:

Field	Notes
`viewSegmentId`	Segment of users who can view the board. Leave empty to allow everyone.
`submitSegmentId`	Segment of users who can submit new requests. Typically narrower than view — e.g. only paying users can submit.

Use this to keep the request board signal high. Only Pro users can submit; everyone can view and vote.

Public roadmap

Field	Notes
`publicRoadmapEnabled`	When on, exposes `https://roadmap.usergist.com/<slug>` and `/v1/public/roadmap/<slug>` for custom read-only clients.
`publicSlug`	3–48 chars, lowercase + hyphens + digits. The URL component.

Branding

Field	Notes
`logoUrl`	Shown on the public roadmap header.
`accentColor`	Hex `#rrggbb`. Active states and upvote highlights.
`coverImageUrl`	Hero image at the top of the public page.
`introCopy`	Up to 500 chars. Markdown supported. The text that sits under the cover.

Notification rules

Triage actions can notify followers automatically.

Rule	Triggers when
`transitions`	A request's status changes — fires per transition (e.g. `under_review → planned`).
`responseFirst`	First admin response is posted.
`responseEdit`	Admin edits an existing response.
`templateOverrides`	Per-status copy overrides for the outgoing notification body.

Notifications flow over in-app + push if the follower has consented to those channels.

Feature requests triage view in the dashboard. — Feature requests triage view. Configuration lives under Requests → Settings.

Triage board

The board is where your team works. Three views:

Kanban — grouped by status, drag-and-drop between columns.
Table — sortable + filterable list.
Detail — full request thread with comments.

Sort

Value	Notes
`top`	Highest vote count first.
`newest`	Most recently submitted.
`recently_updated`	Most recent triage activity (status change, response, comment).

Filters

Status — multi-select across under_review, planned, in_progress, shipped, declined.
Personal filter — submitted (by me) · upvoted · following.
Hidden — show requests admin-hidden for moderation.
Search — debounced (300 ms) across title + body.

Statuses

Status	Default order	Meaning
`under_review`	1	Open for discussion; no commitment.
`planned`	2	On the roadmap. We will build this.
`in_progress`	3	Active development.
`shipped`	4	Live. Followers are notified.
`declined`	5	Won't build. Followers are notified with the reason.

Bulk operations

Select multiple cards to:

Change status (up to 200 at once).
Merge — pick a canonical + duplicates. Votes and followers transfer; comments preserve.

Developer responses and hide / unhide moderation are available on an individual request.

Feature requests list / triage view. — Feature requests triage. Switch to kanban or detail view from here.

In-app surface

Two ways your app talks to requests:

// Hosted UI (recommended) — UserGist renders the full board
UserGist.openRequestsBoard()
UserGist.openRequestDetail('req_abc123')
 
// Or build your own UI on the data APIs
const { items } = await UserGist.getRequests({ statuses: ['planned'], q: 'dark' })
await UserGist.voteOnRequest('req_abc123', true)
await UserGist.followRequest('req_abc123', true)
UserGist.submitRequest('Dark mode', 'A system-aware theme would help.', (error, request) => {
  if (error) console.error(error)
})
 
const comments = await UserGist.getComments('req_abc123')
await UserGist.postComment('req_abc123', 'Yes please.')

Optimistic semantics (identical on every SDK):

Voting auto-follows the request.
Un-voting does not unfollow.
Vote / follow tap updates the UI immediately and reconciles with the server.

Public roadmap

Once publicRoadmapEnabled is on, three URLs are live:

https://roadmap.usergist.com/<slug> — branded HTML page.
https://roadmap.usergist.com/<slug>?embed=1 — chrome-free version for iframe embedding.
GET /v1/public/roadmap/<slug> — JSON for custom integrations.

See Guides → Embed the public roadmap.

Closing the loop

When an operator changes status or posts a developer response, UserGist's request notification service applies the configured transition/response rules and notifies followers over their eligible in-app and push channels.

API

GET /v1/apps/:appId/requests — list (admin)
POST /v1/sdk/requests — SDK submission
PATCH /v1/apps/:appId/requests/:requestId/status — change status
PATCH /v1/apps/:appId/requests/:requestId/moderation — hide or unhide
POST /v1/apps/:appId/requests/merge — merge duplicates
GET /v1/public/roadmap/:slug — public roadmap data

Comment, vote, and follow endpoints all under the same family. Canonical schemas: apps/api/src/schemas/requests.ts.

What's next

Feature requests on websites

Use the Web SDK to open the request board or a request detail, submit ideas, vote, follow and manage comments. Participation requires explicit activation and feedback consent. The launcher is optional and off by default.

Mutations can return { queued: true, pendingId } while waiting for connectivity or earlier pending work. Treat that as saved locally instead of submitting again. The SDK sends retries and newer actions in order. Loading the board and opening request details require a connection. Browser notification push is not included.