Promote an insight into a request
Promotes the insight {id} into a request of its own — the way back from
link-insight.
kind becomes issue, any link to another request is cleared (that request's
linkedInsightCount is recounted), and the row is a post again: GET /v2/posts/{id} answers
it, and GET /v2/posts lists it.
The promoted request is given the workspace's default status if it had none, is filed on the
internal board (its previous board is kept as the request's source category), and is created
hidden from the portal — publish it with PATCH /v2/posts/{id} when you want customers to
see it. It then announces itself like a freshly created request: the post.created webhook fires
and the workspace's tracker integrations receive it, subject to the same rules as any other
creation. Featurebase also looks for other existing insights that support the new request, in the
background.
Calling this on a post that is already a request is a no-op and returns it unchanged.
Request
No body. The insight is named by the path.
Response
The resulting request, in the standard post format.
Response
Success
When kind is 'insight', where exactly the insight points back into its origin: an insight source record with character ranges into its fullText, or the native conversation/message/comment/post ids.
ID of the admin assigned to this post, null if unassigned
507f1f77bcf86cd799439013Post content in HTML format
<p>It would be great to have a dark mode option for the dashboard.</p>Present and true only on POST /v2/posts, when the request carried a source.externalId that already had a post. The existing post is returned unchanged with HTTP 200; a newly created post returns HTTP 201 without this field.
truetrueEstimated completion time as ISO 8601 timestamp, null if not set
2025-01-01T00:00:00.000ZWhen kind is 'insight', the triage grouping key (source record id, conversation id, origin post id, or the insight's own id for singletons). Legacy insights may be null and group as singletons.
Provenance of an insight: which channel it came from and how it was captured.
Present only on POST /v2/posts: the intakeMode the post was processed under ('request' when the request named none). On an idempotent replay (deduped: true) this is the mode the post was ORIGINALLY created with.
request, feedbackrequestDiscriminates an actionable work item ('issue') from a customer submission whose claims were extracted into insights ('record' — not a work item). Defaults to 'issue' for all pre-existing posts. Default list responses return issues only; pass kind='record' to opt in. Raw signal ('insight') is never returned by the posts resource — insights are served by /v2/insights.
issue, insight, recordissueNumber of insights linked to this issue as supporting evidence. Only meaningful when kind is 'issue'.
0When kind is 'insight', the ID of the issue this insight supports. Null when the insight is unlinked or when kind is 'issue'.
Total opportunity amount from linked HubSpot deals and Salesforce opportunities
30000True when the issue is hidden from portal/public surfaces. Missing stored values are returned as false.
falseFull URL to view the post
https://feedback.example.com/p/add-dark-mode-supportOn POST /v2/posts — queued: a processing run (claim extraction or the Organize rewrite) was enqueued and its result lands asynchronously on the post. skipped: nothing was enqueued; reason says which gate decided ('request_mode' for every intakeMode: 'request' create). existing: the create was an idempotent replay and the post was not processed again. On GET /v2/posts/{id} this field is present only for posts created with intakeMode: 'feedback' and reports how far that processing has got ('queued', 'processing', 'complete', 'needs_review', or 'skipped' with the same reason the create returned), with results listing what was made of the submission once the run has finished.