An immutable request record adds a new field in the middle of its constructor parameter list to match updated API documentation, with each parameter still carrying its own `@JsonProperty`. Does that reordering risk Jackson binding an existing client's JSON values to the wrong parameters?

No, and the reason is specific to how @JsonCreator constructor binding actually works, not a general Jackson guarantee. With a no-arg-constructor-and-setters class, Jackson would assign properties one at a time as it encounters them in the JSON, with the object half-built in between — but a constructor has no such thing as "half-called," so Jackson does something different for @JsonCreator: it buffers every incoming JSON property by name as it reads the token stream, in whatever order the JSON actually presents them, and only once every required value is collected does it call the constructor exactly once, with the complete argument list assembled by matching each @JsonProperty name to its declared parameter. Moving a parameter to a different position in the constructor changes where it sits in that final call, but the buffer resolves everything by name first — so sku and quantity land in the right places regardless of what order the client sent them in or where the parameter now sits in the signature.