List items

Maximum records to return. parseLimitOffset does not reject out-of-range values, it rewrites them: anything above 100 (constants.MaxLimit) is clamped to 100 with no signal to the caller, 0 and any negative other than -1 fall back to the default 10, and -1 (constants.LimitSkipDataFetching) is a counts-only mode — ShouldSkipDataFetching short-circuits the fetch and the envelope comes back with total and total_unfiltered filled in and data empty. A non-numeric value is 400 common.invalid_input.

Records to skip.

Sort expression. The parser splits on commas and understands ONLY an optional leading minus for descending — sort=-created_at,name. There is no :asc / :desc suffix: ParseSortFields looks the whole token up in the field map, so sort=created_at:asc finds no such field and answers 400 query_m.invalid_sort_field. Omitted, the list is ordered by created_at descending. Note that sort is parsed on the fetch pass only: GetTotal runs with isCount true and skips it, and the fetch is not reached when the count is 0 — so an unknown sort field is 400 on a populated tenant and 200 on an empty one.

JSON-encoded filter criteria. A value that is not valid JSON is rejected with 400.

Free-text search. Also accepted as search — parseStandardQueryParameter routes both spellings to the same slot. It is honoured on this route because the generic count and fetch both run ExtractTextSearch, which reads it. The equivalent inside the search map is search._text; the reserved field name is _text, not search_text.

Group results by this field; data then comes back as an object keyed by the field value instead of an array.

Return one row per distinct value of this field. The field must be in validFields — anything else is 400 common.invalid_input, on the count pass as well as the fetch. The count then runs COUNT(DISTINCT ) and the fetch runs DISTINCT ON () with a forced descending sort on that same column, which is applied before your own sort.

Per-field filter, optionally with an operator suffix (.eq, .ne, .gte, .lte, .gt, .lt, ...). An unrecognised field is rejected by the shared parser.

Locale for the localised title and description. Honoured on GET /v1/items and GET /v1/items/{id} only — those are the two handlers that read constants.AcceptLanguage. Resolution is four steps, not two: exact match on the stored locale map; then the base language, so en-US falls to en; then config.DefaultLanguage(), which is the app-config default_language and only equals en when that key is unset; and finally, when none of those is present in the map, the FIRST KEY IN ALPHABETICAL ORDER of whatever the item stores. So an item holding only de and fr, requested with Accept-Language: en or with no header at all, comes back with the German text in title_loc and no indication that the locale is not the one asked for. title_loc is never empty for a populated item.