Valid JSON, Still HTTP422 Through a Proxy? Check the Rejected Instruction

An authorized API request returns422 through a residential proxy. Its JSON parses locally, so the integration rotates the exit and sends the same payload again. That does not address a rejected instruction or field constraint. Preserve the actual response and compare the API contract before changing the route. This guide is a controlled diagnostic design, not a report of tested 98IP behavior.

1. Identify the real response and its contract

HTTP422 Unprocessable Content indicates that the server understood the content type and the content syntax, but could not process the instructions. An unchanged repeat should be expected to fail again. Valid JSON proves syntax, not that a value, relationship or operation is valid for the endpoint.

Save the actual HTTP status, method, final path, response content type and a non-secret attempt ID. Separate a proxy CONNECT response from the target exchange inside TLS. An SDK code named422 or a JSON field containing422 is not a substitute for the HTTP status. If a wrapper replaces the original body with a generic proxy error, capture a redacted diagnostic response before that transformation.

2. Read structured evidence without guessing

Check the endpoint version, schema and documented business rules with the owner. Inspect required fields, numeric versus string types, enum identifiers, array shape, date constraints, dependent fields and resource relationships. Do not translate stable enum codes merely because the user interface uses another language. Check omitted, null and empty values separately if the contract distinguishes them.

Some APIs use application/problem+json with a problem type and occurrence information; others use their own error format. Use documented stable codes or structured field errors for classification, rather than scraping localized human-readable messages. RFC9457's example field-error extension is not a universal mandatory errors array. Preserve unknown structures as evidence and do not automatically fetch every URI returned in an error.

A reported field can be the first detectable symptom rather than the only defect. If the response points to a constraint or account/resource state, ask the responsible operator for the approved remedy. Do not invent a missing value, change account identity, buy an upgrade or delete records merely to make validation pass.

3. Build a harmless valid/invalid pair

1. Use an owned staging validation or dry-run endpoint with documented semantics and no real transaction. Agree on independent expected outcomes and how the receiver will correlate each request.
2. Create one owner-reviewed valid fixture. Create a second fixture by changing just one field to a syntactically valid but disallowed value, such as an unsupported enum in a synthetic catalog. The owner must confirm the expected rejection status; not every API uses422 for every validation failure.
3. Record the final serialized payload and the receiver's decoded values, using synthetic data only. A source-language object can differ from its transmitted representation after defaults, coercion or middleware.
4. Run each fixture once through an approved baseline and the chosen proxy route, holding method, endpoint, version, account state and headers fixed. Verify actual egress; keep session policy stable.
5. Confirm the valid fixture reaches its independent success marker and the invalid fixture reaches the documented rejection. Preserve any route difference without immediately assigning cause.
6. Correct only the evidenced invalid field under the owner's contract, then submit the corrected fixture under a small attempt budget and verify its acknowledgement.

If no direct baseline is authorized, document its absence. A fabricated422 response can test the client's error handling, but it cannot prove the real API received or validated the request. Mark that test separately. Do not send intentionally invalid customer transactions to a public production endpoint.

4. Classify the first observed mismatch

• Locally valid object changes before serialization: inspect defaults, type coercion or dropped fields in the application.
• Serialized payload matches but receiver values differ: inspect the documented representation and the receiving parser with the owner.
• Receiver values match but only the invalid fixture fails: follow the evidenced validation rule rather than rotating IP.
• Both fixtures fail: check version, authorization context, resource state and the owner's valid fixture assumption.
• Only one route fails: compare final endpoint, deployment version, redirects and receiver correlation before blaming the proxy.
• Response structure is unavailable or contradictory: record the limitation and escalate with redacted evidence; do not manufacture a field diagnosis.

For an owned integration, repair the first proven boundary and rerun the valid, invalid and corrected fixtures. Retain the invalid negative control so a repair does not simply disable validation. Do not globally convert all fields to strings, replace every missing value with null or delete validation checks.

5. Stop unchanged retry loops and reconcile writes

Separate validation rejection from transport retry policy. Count attempts inside the SDK and application together; an outer retry can multiply hidden repeats. An unchanged rejected payload should stop until the documented input or relevant state changes. Backoff alone does not correct an invalid enum or relationship.

For batches, consult the API's atomicity and per-item outcome contract. A422 alone does not establish that every item in a nonstandard or partially processed workflow had no effect. If a previous write outcome is unknown, use the owner's status/read-back and idempotency procedure before resubmission. Do not create a new operation key just to repeat an uncertain write. The POST timeout and duplicate-submission guide covers that separate recovery problem.

Keep a minimal evidence packet: endpoint/schema version, method, actual status, structured error code or field reference, redacted fixture difference, correlation IDs and verified outcome. Do not include proxy credentials, authorization headers, cookies or real customer payloads.

6. Control the 98IP route and acceptance record

When an authorized API comparison needs a residential route, consult the 98IP residential proxy product page and follow the configuration documentation and account-supported parameters. Fix the request contract before comparing exits, and record actual egress.

A proxy does not repair invalid business instructions or guarantee a target accepts a payload. An ordinary non-intercepting HTTPS proxy cannot edit encrypted fields. Limit traffic and requests, review actual account usage, and respect target authorization. No tested speed, compatibility or billing outcome is promised here.

• Actual HTTP422 and target layer are evidenced, not inferred from an SDK label.
• Schema version and relevant input/state constraints are documented.
• Valid, one-field-invalid and corrected fixtures have independent expectations.
• Serialized and receiver values are compared without leaking secrets.
• Negative validation remains effective after the repair.
• Unchanged retries stop, and uncertain batch/write outcomes are reconciled separately.

Does valid JSON rule out a request problem? No. Syntax and instruction validity are different checks.

Will a new IP usually fix the same422 payload? It does not correct the rejected field or state. Investigate a route difference only when controlled evidence shows one.

Does every422 contain a standard field-error list? No. Use the API's documented format and preserve missing evidence honestly.