Symptom
The PUT that turns on the customs-clearance flag returns 200 SUCCESS. Re-fetch, and the value is unchanged. Change the payload, change the state, same result. Every one of several thousand items was like this.
Cause
When the item's delivery-method field holds a particular value, the customs-clearance flag is ignored. Nothing is wrong with the flag itself; another field decides its fate. And the delivery-method field is fixed at creation: try to change it and you get 400.
"Some fields can only be set at creation" and "A field can be one-way" above are about a field that won't change itself. This one won't change and blocks another. New shape.
★ Don't stare at the field that won't take. Find the higher-level setting that governs it. You can look at the dead field all day and the cause won't appear, because the culprit is a different field.
Second case: a "missing" 400 isn't asking for a value
Registering a branded item returned 400: "product identifier missing." Filling in the identifier made it keep getting rejected.
When the brand field has a value, that validation fires; leave the brand empty and the validation disappears. "Missing" didn't mean "supply a value." It meant "this combination is invalid."
★ The field an error message names is rarely the cause. When you're blocked, don't only look for a value to fill in; look for the field that triggers the validation and turn it off. (Brand is one-way, so starting empty is the direction that keeps options open.)
This is the opposite prescription from an entry above. Keep them apart.
"Passing at creation time doesn't mean passing now" says "replace the value, don't delete." That case is a required attribute: remove it and you get a different error. This case has a separate field that triggers the validation. Different mechanism, opposite fix. Don't apply one remedy to every 400.
Fix
Verification
★ Opening a sample of correctly registered items beats the docs. The second case was answered not by reasoning but by opening four items that were selling fine: all three identifier attributes were empty strings. A payload that passes already exists in your own account. Get a working one and lay it side by side.
And peel one layer and the one beneath appears. After the 400s stopped, "normal processing resumed, ~2,500 items" went into the log. Hollow: the 400 was gone and the value still wasn't landing. A rejection disappearing and a value applying are different events.