List countries (v2)

Maximum records to return. This route does NOT go through the shared 100-item clamp: the handler calls query.GetLimitWithoutMaxFilter, which re-reads the raw parameter, so a large limit is honoured as given. 0 and negatives other than -1 fall back to 10; a non-numeric value is rejected with 400 common.invalid_input. -1 is the count-only mode — ShouldSkipDataFetching returns total and total_unfiltered with an empty data array.

Records to skip. A negative value is neither rejected nor honoured — parseLimitOffset returns 0 for it, so ?offset=-10 silently returns the first page.

Sort expression. ParseSortFields splits on commas and understands ONLY an optional leading minus: sort=order ascending, sort=-order descending, sort=-order,name for two keys. There is no :asc / :desc suffix — the whole token is looked up in validFieldsV2, so sort=order:asc is not found and answers 400 query_m.invalid_sort_field. BUT THAT CHECK ONLY RUNS WHEN ROWS ARE FETCHED. getAllQueryStorage.applyParams sorts only on the data pass (isCount == false), and SrvGetAllCountriesV2 skips that pass entirely when the count is 0 or limit=-1. So ?sort=order:asc&limit=-1, and the same sort against a search that matches nothing, both answer 200 with the bad key silently accepted. stack behaves the same way. A 200 is not proof the sort key is valid.

JSON-encoded filter criteria — ACCEPTED AND THEN IGNORED on this route. ParseQueryJSON never extracts a filter key into models.Parameters, and get_all_service assigns Filter from an input field SrvGetAllCountriesV2 never sets, so it stays nil. ?filter={"active":true} returns exactly the same unfiltered page as omitting it. The only real effect is the 400 when the value is not valid JSON. Use search. to filter.

Free-text search over the searchable fields — iso_alpha_2, iso_alpha_3, iso_numeric, icon, emoji, phone_prefix, name and description. Also accepted as search. Both forms are translated into _text.like; the explicit search._text. form described under search. reaches the same expression with a choice of operator.

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

Return distinct values of this field.

Per-field filter with an optional operator suffix (.eq, .ne, .gte, .lte, .gt, .lt, .in, .nin, .like, .start_with, .end_with). An unrecognised FIELD is answered 500 query_m.invalid_search_field, not 400 — that branch of validateFieldName omits WithCode. A name that fails the character regex is a normal 400, query_m.invalid_field, and a bad VALUE on a recognised field is a normal 400, query_m.invalid_search_value. TWO SUFFIXES PARSE BUT DO NOT VALIDATE. ParseFieldAndOperator also recognises .ilike and .contains, so ?search.name.ilike=zurich splits cleanly into a field and an operator — and then validateOperator rejects it, because validOperators holds neither. The answer is 400 query_m.invalid_operator, a fifth query_m code. Use .like, which is synonymous. THE RESERVED _text FIELD. search._text is not a column: validFieldsV2 maps it to an expression concatenating iso_alpha_2, iso_alpha_3, iso_numeric, icon, emoji, phone_prefix, name and description, and ExtractTextSearch peels search._text.* off before ordinary field validation, so the 500 above does not apply to it. It takes the WIDER operator set — .like, .ilike, .contains, .eq, .start_with, .end_with — which is where .ilike and .contains are legal. A bare search._text means .like. Anything outside that set is 400 query_m.invalid_operator, and two _text operators in one query are 400 query_m.invalid_search_value.