Skip to main content
GET
List / search features

Authorizations

X-API-Key
string
header
required

Team-scoped API key created in the app (Settings → API Keys). Sent as X-API-Key: <key> on every request. The header name apikey is also accepted as an alias.

Query Parameters

show_all
boolean
default:false

Include features below the team's adaptive size floor. Default false.

q
string

Free-text search over titles and content.

search_mode
enum<string>
default:lexical

Lexical substring matching against the feature's own title and description, or semantic matching against feature embeddings.

Semantic search returns rows best-match-first and therefore OVERRIDES sort. Relevance order and size order are mutually exclusive: a caller relying on sort=insight_count for scope-aware ordering loses it when semantic is enabled.

Semantic requests share ONE rate budget with /themes; they are not separately allowanced.

Available options:
lexical,
semantic
min_similarity
number<float>
default:0.5

Minimum cosine similarity for semantic search. Valid only when search_mode is semantic.

Required range: 0.3 <= x <= 1
allow_fallback
boolean
default:false

Permit falling back to lexical when an embedding cannot be generated. Default false, so such a request fails with 503 rather than silently returning a different result set. The response always reports the mode that actually ran.

theme_id
string<uuid>

Return only the features under this theme.

product_id
string<uuid>

Filter by one product ID from /products.

feature_area_id
string<uuid>

Filter by one child feature-area ID from /areas. A feature area is the subject area an insight is filed under; it is NOT a buildable feature ID from /features, and the two are never interchangeable.

product_area_id
string<uuid>

Return only features with supporting insights filed anywhere under this parent product area, with insight_count and unique_customer_count recomputed over exactly that evidence. This is feature_area_id one level up: a product area is the parent of many feature areas, so it is the coarser cut of the same question. Combines with every other filter using AND, so pairing it with feature_area_id narrows to that one child area — and yields nothing when that area sits under a different product area.

ARCHIVED child areas are excluded, which feature_area_id does not do: naming an archived area directly still counts its evidence, while its parent product area does not. A product area whose children are all archived therefore returns an empty list. /areas with include_archived=true sums archived children into a product area's insight_count, so that total can exceed what this filter returns.

product_feature_id
string<uuid>

Return only the feature with this ID. On THIS endpoint the parameter names the listed resource itself, so it selects that one feature; on /insights and /themes the same parameter instead means "linked to this feature". Combines with every other filter using AND, so pairing it with feature_area_id answers "does this feature have evidence in that area, and how much" in one call. Use /features/{id} to fetch one feature with its evidence, severity breakdown and affected customers.

status
enum<string>
Available options:
active,
declined,
shipped,
parked
sort
enum<string>
default:ric_score
Available options:
ric_score,
insight_count,
unique_customer_count,
created_at
limit
integer
default:50

Page size (max 200).

Required range: 1 <= x <= 200
offset
integer
default:0

Number of records to skip.

Required range: x >= 0

Response

A page of features

data
object[]
required
pagination
object
required
search_mode
enum<string>
required

Search mode actually applied. Lexical indicates lexical/default search or an explicitly allowed fallback.

Available options:
lexical,
semantic
min_similarity
number<float> | null
required

Applied semantic threshold, or null when the applied mode was lexical.