Add 400 response for invalid sort.order on POST /contacts/search#567
Conversation
The contacts search endpoint now returns 400 with an invalid_sort_order error when sort.order is not "ascending" or "descending". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
zilleeizad-inter
left a comment
zilleeizad-inter
left a comment
There was a problem hiding this comment.
Review question on the new contacts-search 400 example — for the author's consideration.
| value: | ||
| type: error.list | ||
| errors: | ||
| - code: invalid_sort_order |
There was a problem hiding this comment.
This 400 example omits request_id, but the 401 example just above on this same operation includes one — and nearly all error.list examples in this spec carry it. Should we add a request_id here so the example matches the established shape?
There was a problem hiding this comment.
Added — request_id is now on the 400 example (commit 1d08c79), matching the 401 just above and the rest of the spec. This keeps it in sync with the developer-docs PR (#999), where the same change landed.
- Add a contact_search_request schema (sort.field + sort.order enum: ascending/descending, default descending) and point POST /contacts/search at it. Conversations and tickets searches keep the shared search_request. - Add request_id to the 400 invalid_sort_order example for parity with the rest of the spec. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Reword so valid values aren't implied to 400: "Values other than `ascending` or `descending` return a 400 error" instead of "Any other value". Keeps the contacts search schema in sync with developer-docs. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
zilleeizad-inter
left a comment
zilleeizad-inter
left a comment
There was a problem hiding this comment.
Approving. Verified byte-identical to the source-of-truth developer-docs#999 (this spec is manually derived from it): the 400 example, the requestBody repoint to contact_search_request, and the new schema block all match. request_id present in the 400 example per spec convention; scoping to the Preview spec (descriptions/0/) is correct since the backend validation is version-gated.
2 participants
Why?
The contacts search endpoint previously coerced any unrecognised
sort.ordervalue todescending. It now rejects unrecognised values with aninvalid_sort_order400, so the spec should document that response.How?
Add a
400response (with aninvalid_sort_orderexample) to thePOST /contacts/searchoperation.sort.orderacceptsascendingordescending.Generated with Claude Code