> ## Documentation Index > Fetch the complete documentation index at: https://gleanfeed.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Endpoints > The feedback, changelog, roadmap, and workspace operations in the Glean Feed REST API. All paths are relative to the [base URL](/api/overview#base-url) `https://app.gleanfeed.com/api/v1`. Each operation lists the [scope](/api/scopes) it requires. Responses use the shared [envelope](/api/overview#response-envelope); list endpoints support [cursor pagination](/api/overview#pagination), and create endpoints accept an [`Idempotency-Key`](/api/overview#idempotency). The full request and response schemas are in the OpenAPI document at `/api/v1/openapi.json`. ## Feedback A feedback request has a derived `stage` (`pending`, `in_review`, `planned`, `in_progress`, `completed`, `closed`), vote and comment counts, and a title and description. Set the product stage with `/stage`: `pending` and `closed` are private/internal, while `in_review`, `planned`, `in_progress`, and `completed` are public portal stages. The legacy `/status` endpoint sets the stored moderation state (`pending`, `approved`, `rejected`, `spam`) directly. | Method & path | Scope | Description | | ------------------------------------ | ---------------- | ------------------------------------------------------------ | | `GET /feedback` | `feedback:read` | List requests. Filter by `stage`, `board`, or `search`. | | `POST /feedback` | `feedback:write` | Create a request. Idempotent. Accepts capture context. | | `GET /feedback/{id}` | `feedback:read` | Get one request. | | `PATCH /feedback/{id}` | `feedback:write` | Update a request's title or description. | | `PATCH /feedback/{id}/stage` | `feedback:write` | Set the request's product stage. | | `PATCH /feedback/{id}/status` | `feedback:write` | Set the request's moderation status. | | `GET /feedback/{id}/comments` | `feedback:read` | List comments on a request. | | `POST /feedback/{id}/comments` | `comments:write` | Post a comment or staff reply. | | `POST /feedback/{id}/promote` | `roadmap:write` | Create or update the request's linked roadmap item. | | `GET /feedback/{id}/send-to-linear` | `roadmap:write` | Preview the configured Linear destination and issue. | | `POST /feedback/{id}/send-to-linear` | `roadmap:write` | Create or return the accepted request's linked Linear issue. | `POST /feedback` is the recommended server-side path for in-app "Give feedback" buttons: your server holds the API key and forwards each submission. Alongside `title`/`description` it accepts optional context — `boardId` (a board UUID or slug; omit it to use your first board that accepts requests), a `submitter` (`email`/`name`/`externalId`, so the request is attributed to a real customer), a `sourceUrl`, and up to 10 limited `metadata` key/value pairs. Source URL and metadata are private team context — they're never shown on the public portal. For the browser-direct signed alternative and copy-paste examples, see the [feedback quickstart](/headless/feedback). A new `submitter` counts toward the workspace's [tracked customer limit](/portal/accounts#tracked-customer-limits). If a Free or Starter workspace is at its limit, creating another submitter returns `403 forbidden`. Requests attributed to an existing submitter continue to work, and omitting `submitter` creates anonymous feedback without adding a tracked customer. Feedback write operations also accept an optional `X-Glean-Feed-Agent` header. Use a stable, low-cardinality name of up to 64 letters, numbers, spaces, dots, hyphens, or underscores. Glean Feed records it in audit context only; the header cannot select a workspace or grant permission. Promotion requires `status` (`planned`, `in_progress`, `done`, or `closed`) so an integration cannot infer a public commitment. Add an optional `targetDelivery`, or send `null` to clear an existing target. The response returns both `roadmapItem` and `linkedFeedback`; repeating the same request returns the existing link instead of creating another roadmap item. Before sending accepted feedback to Linear, call `GET /feedback/{id}/send-to-linear` with the same optional overrides you plan to submit. It returns the exact request title, connected team/project, proposed issue fields, and any active issue link so you can show a concrete confirmation. After confirmation, `POST` the overrides. The operation uses the existing Linear connection and configured defaults, preserves the Glean Feed backlink, and returns an active manual-created link on retry instead of creating another issue. A missing, revoked, or stale connection returns guidance to connect or reconnect Linear. ## Changelog A changelog entry has a `state` of `draft` or `published`. Listing returns drafts as well as published entries. Alongside title and body, an entry can carry a version label, tags, linked feedback requests, per-entry `reactionsEnabled`/`commentsEnabled` toggles, and an optional `scheduledPublishAt` future publish time. Publishing now makes an entry customer-visible and, the first time it goes live, emails customers with an address who have not opted out of changelog emails; publishing an already-published entry is a no-op that returns `200` (no re-send). Use `scheduledPublishAt` with an optional IANA `scheduledTimezone` when creating or updating a draft. Send `scheduledPublishAt: null` on `PATCH /changelog/{id}` to clear a scheduled publish time. | Method & path | Scope | Description | | ------------------------------- | ----------------- | --------------------------------------------------------------------------------------------------------- | | `GET /changelog` | `changelog:read` | List entries, including drafts. | | `POST /changelog` | `changelog:write` | Create a draft (title, body, version, tags, linked requests, schedule, toggles). | | `GET /changelog/{id}` | `changelog:read` | Get one entry. | | `PATCH /changelog/{id}` | `changelog:write` | Update fields: title, body, version, tags, linked requests, schedule, toggles. | | `POST /changelog/{id}/publish` | `changelog:write` | Publish the entry (emails customers with an address who have not opted out on first publish). Idempotent. | | `DELETE /changelog/{id}` | `changelog:write` | Permanently delete the entry (cascades to links, reactions, comments). | | `GET /changelog/{id}/comments` | `changelog:read` | List comments on an entry. | | `POST /changelog/{id}/comments` | `comments:write` | Post a comment or staff reply on an entry. | ## Tags Tags are a workspace-level taxonomy you attach to changelog entries via `tagIds`. Those write fields take tag **ids**, so list the tags first to discover the id you want. | Method & path | Scope | Description | | ------------- | ---------------- | -------------------------------------------- | | `GET /tags` | `changelog:read` | List the workspace's tags (id, name, color). | ## Roadmap A roadmap item has a `status` of `planned`, `in_progress`, `done`, or `closed`, plus a sort order and optional `targetDelivery`. New items default to `planned`. Use `targetDelivery: { "precision": "quarter", "date": "2027-04-01" }` for quarter targets, `targetDelivery: { "precision": "date", "date": "2027-03-15" }` for exact dates, or `targetDelivery: null` to clear it. Creating a roadmap item also creates a backing feedback request so the item is votable, commentable, and appears on the admin roadmap board — just like promoting a request from the dashboard. Pass `boardId` to choose the request's board, or omit it to use the workspace's first submittable board. | Method & path | Scope | Description | | ---------------------------- | --------------- | ----------------------------------------------- | | `GET /roadmap` | `roadmap:read` | List roadmap items. | | `POST /roadmap` | `roadmap:write` | Create an item (+ backing request). Idempotent. | | `GET /roadmap/{id}` | `roadmap:read` | Get one item. | | `PATCH /roadmap/{id}` | `roadmap:write` | Update title, description, or targetDelivery. | | `PATCH /roadmap/{id}/status` | `roadmap:write` | Move the item to a stage. | ## Workspace | Method & path | Scope | Description | | ---------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------- | | `GET /workspace` | `workspace:read` | Read a workspace summary: name, plan and limits, feedback and roadmap counts, and setup state. Contains no personal data. | Every read and write is scoped to the workspace of the credential. An `{id}` that belongs to another workspace returns `404`, and a write against it changes nothing.