JSON IDs Change After a Proxy Request? Check Integer Precision Before Retrying

An authorized market-data response arrives with HTTP 200, yet two product IDs become identical after ingestion. Before rotating proxies, compare the identifier at each processing boundary. A valid JSON document can still lose identifier precision when a client treats every number as a floating-point value.

This guide proposes a small controlled acceptance test for JSON data received through a proxy. It focuses on exact identifiers used for deduplication and joins, rather than pagination, NDJSON framing or price arithmetic. The fixtures are synthetic; no production fault rate or 98IP compatibility result is claimed.

1. Define identifiers as identifiers

Ask the destination owner which fields are opaque IDs and which are quantities. Record the documented JSON type, allowed characters, maximum length and whether leading zeros or case matter. A digit-only ID does not automatically need arithmetic. Do not change the destination's contract merely to make a local parser accept it.

If the owned API can be changed, an explicitly documented string representation is often easier to preserve across runtimes. If the API requires a JSON numeric integer, select a parsing and storage path that retains the exact value before ordinary floating-point conversion. An unsupported value should be rejected or quarantined with its original evidence, not silently rounded.

MDN identifies JavaScript's maximum safe integer as 9007199254740991. Larger integers are not all exactly distinguishable using Number. This is a limit on exact integer handling, not the largest magnitude JavaScript can represent; it should not be generalized to every language or parser.

2. Build an independent, exact fixture

1. Prepare an owned endpoint with two records whose numeric IDs are 9007199254740992 and 9007199254740993, plus distinct harmless marker fields.
2. Store the expected ID spellings in the test manifest as strings. Do not construct this fixture by first converting the IDs to JavaScript Number.
3. Add a separate string-ID variant, a normal small integer and, only where permitted by the schema, a string with a leading zero.
4. Declare the expected record count and exact ID-to-marker mapping. Both large IDs must remain distinct.
5. Use the same fixture version on the approved baseline and proxy routes, with a small request budget and fixed deadline.

The two large example IDs are deliberately chosen to expose a common unsafe conversion. This article does not report executing the fixture. A fixture generator that has already rounded an ID invalidates the test before the proxy is involved.

3. Capture representation before parsing

Check status and content type, then retain the bounded, sanitized response representation before JSON deserialization. Be explicit about automatic decompression: compare the same representation layer on both routes, rather than hashing compressed transfer bytes on one and decoded body bytes on the other.

For an owned deterministic fixture, compare its representation bytes or hash against the approved manifest. For a live changing response, do not expect two separate requests to be byte-identical; use the captured response from one request as that run's parsing reference and keep route conclusions appropriately limited.

The 98IP dynamic residential IP page is relevant when selecting a product for authorized market-data route testing. Check the current connection method and account options through the API configuration page. Proxy access does not specify your target's JSON schema or your client's numeric precision.

4. Inspect each conversion boundary

Use five evidence columns: raw response spelling, parsed value and runtime type, normalized application ID, stored value and type, and exported/reloaded value. Compare each with the manifest's exact string and marker association. Record the first point at which distinct IDs become equal.

A JSON reviver that receives an already rounded number cannot recover the missing digits merely by converting that number to a string or BigInt. Preserve the original numeric token using a suitable lossless parser, or a source-token facility supported and verified in the chosen runtime. Check actual runtime support before relying on such a facility.

Do not apply a regular expression to quote arbitrary numbers in JSON. It can affect quantities, strings or unrelated fields and conceal schema errors. Use field-aware parsing under the documented contract, and fail clearly when an unexpected type is received.

If the raw fixture is correct and the parsed IDs have collapsed, investigate the parser or conversion. If parsing is exact but the database or export changes the value, inspect that later boundary. If the owned fixture's raw response differs, investigate response generation, intermediaries and client body transformations without prematurely assigning blame to the proxy.

5. Test joins and round trips, not just display

A screen showing both rows does not prove safe deduplication. Join each ID to its expected marker, deduplicate by the intended exact key and reload the stored result. The expected outcome is two distinct IDs with their original marker associations, not simply a row count of two.

Keep keys textual when that is the documented contract, and prevent downstream spreadsheets or ETL importers from silently converting them to numbers. Specify column types at import and verify the value after reopening. A display format with more digits cannot restore precision already lost earlier.

When an ID is intentionally normalized, define the operation explicitly. Removing leading zeros or changing case is allowed only if the destination's identifier semantics permit it. Do not reuse numeric normalization intended for quantities on opaque identifiers.

6. Use a small failure and recovery matrix

• Exact string-ID variant: parsing, storage and reload preserve every character.
• Large numeric pair: the selected lossless path preserves both IDs or explicitly rejects unsupported precision.
• Controlled unsafe conversion: the independent manifest detects the collision instead of accepting the rounded pair.
• Exact parse followed by a numeric storage/import fault: the first failing downstream boundary is identified.
• Unexpected field type: quarantine or reject under the contract rather than coercing silently.
• Corrected pipeline replay: rebuild affected derived keys from retained exact evidence and verify joins before replacing output.

These are unexecuted acceptance cases. Do not simply retry a damaged parsed object through a new IP. If original exact data was not retained, reacquire it under authorization and the destination's request policy. Mark earlier derived output as affected; do not claim converting the rounded value back to a string repaired it.

FAQ and acceptance checklist

Does JSON validity prove ID integrity? No. Syntax acceptance and exact field preservation are different checks.

Should every number become a string? No. Identify opaque keys separately from quantities and follow the documented schema.

• The oracle is exact and independent of the parser under test.
• Raw representation is captured before lossy conversion.
• Distinct IDs remain distinct through joins, storage and reload.
• Unsupported values and unexpected types fail explicitly.
• Recovery starts from exact evidence, not rounded output.
• Only authorized endpoints and synthetic records are used; credentials, personal data and live response bodies are excluded from public reports.