Creating a network object through the city's FDM API returns HTTP 400 (or 422) because the payload is malformed. What is the correct consumer control flow?

HTTP 400 or 422 on an FDM network-object create means the payload failed validation. The correct consumer control flow is to halt that request, surface the validation problem, and fix the body before any new attempt. Retrying the identical malformed payload will not heal schema, type, or constraint errors; it only repeats rejection.

Applying the same exponential backoff used for read timeouts and keeping the identical body treats a deterministic client error like a transient outage. Treating 400 as a soft 429 and sleeping on Retry-After when the header is absent misclassifies validation failure as rate limiting. Converting the call to GET and ignoring the validation failure abandons the create goal and hides the defect.

Exam caveat: some APIs return 400 for other reasons (bad query strings on GET); still, do not blind-retry creates that failed body validation—inspect the error payload. Operational check: log the FDM error body, correct the object fields against the API model, and only then POST again; add a unit test that asserts 400/422 paths do not enter the timeout backoff branch. Map 400/422 to a non-retryable client-error class in your handler taxonomy beside 401/403, separate from timeout and 429 classes. Include the validation message in the operator-facing failure for the network-object create so the fix happens once, not after N identical POSTs.