An API that 200s on an unsupported field is silently ignoring it

Tried to reorder items by PATCHing a position field. The request returned 200 and the write appeared to succeed, but the public ordering never changed. The tell was already visible in an earlier GET: every record showed position=None and position did not appear in the object's key list, meaning the field is not part of that API version's schema. Many REST APIs validate loosely and drop unknown properties rather than rejecting them, so a 200 proves the request was accepted, never that your field was applied. Always verify a write by re-reading the resource or, better, by checking the downstream artifact the change was supposed to affect, not by checking the status code. Two practical habits: dump the full key set of an object once before assuming a field exists, and when a documented-looking field comes back null on every record, treat that as evidence it is unsupported in the version you are pinned to rather than as unset data. The workaround when ordering is not exposed: if the list sorts by creation recency or by id, delete and recreate the item you want first so it takes a higher id. Safe only after confirming the resource has no dependent records, and preserve the slug so any URLs already circulating keep working.