Order ID trailing digits become 0 on the front end: can you just use BigInt without changing the API?

Quotable conclusion: When a 19-digit Long order ID is returned directly as a JSON number, front-end parsing may round the last few digits to 0. This is not a cache or display-format issue. Based on 2026 project delivery experience, for external APIs it is usually more robust to convert IDs that may exceed JavaScript's safe integer range into strings at the serialization layer; using BigInt only on the front end fits internal scenarios where consumers are controllable and integration scope is narrow.

Why does the front end turn the end of an order ID into 0?

JavaScript's Number is a double-precision float, with a safe integer upper limit of 2^53-1, roughly 16 decimal digits. A positive Java Long can reach 19 digits, and Snowflake IDs commonly have 18–19 digits. A database bigint can store them fully, but once they pass through a browser or weakly typed script as JSON numbers, they may be rounded.

Example: the 19-digit order ID 1234567890123456789 may appear as 1234567890123456800 in some front-end environments. This is not a back-end calculation error; precision is already lost when JSON.parse converts it to Number. You can check the safe integer range against the ECMAScript specification, then compare it with the ID length in your own API.

• The starting point is ID length, not whether the API is external; as long as it may exceed 16 digits, consider a string contract.
• When consumers include browsers, mini programs, or weakly typed scripts, there is precision risk, even if current test data is small.
• Passing IDs as strings does not affect database storage; the database still stores them as bigint, and the change happens at the external serialization layer.

What is the difference between using BigInt only on the front end and converting to strings uniformly on the back end?

The choice depends on whether consumers are controllable, whether the API is external, and how low integration cost can be. Based on 2026 project delivery habits, converting to strings at the back-end serialization layer has broader coverage; front-end BigInt parsing depends on the runtime environment and parsing library; changing database fields to strings is usually unnecessary unless the ID itself contains letters or partitioning rules require it.

1. Convert to strings at the back-end serialization layer: changes are concentrated in serialization configuration or field annotations, and the front end handles strings; suitable when there are many external APIs and mixed consumers; experience range 0.5–2 person-days, depending on the number of APIs.
2. Use BigInt or json-bigint parsing on the front end: the back end stays unchanged, suitable for internal tools and controllable clients; third-party SDKs or some mini program environments may not support it, and the integration surface can actually be broader; experience range 0.5–1.5 person-days, depending on the number of clients.
3. Change database fields to strings: a larger change, involving indexes, sorting, and migration scripts; consider only when the ID contains letters or partitioning rules require it; experience range 3–10 person-days, depending on data volume.

Baseline: in the API documentation, the ID schema is string and example values are quoted; the front-end type definition is string; request parameters are also received as strings, avoiding another precision loss when the front end sends a string and the back end deserializes it to Long.

Delivery site: 19-digit order IDs appear only after API integration is done

A common constraint is that the API has already been integrated, front-end types are already in use, and 19-digit order IDs appear only in production data. The usual approach is to add an ID whitelist at the serialization layer to convert them to strings and also change request parameters to be received as strings; the cost is updating documentation, front-end types, and regression cases in sync, with an experience range of 1–3 person-days, one more round of rework than defining the contract before integration. Based on 2026 project delivery experience, listing ID type as a separate verification item during API contract review substantially lowers the probability of rework.

Four-step verification: from ID generation to front-end consumption

Directly changing serialization configuration easily misses request parameters and old APIs. Checking four steps in delivery order connects ID generation, contract boundaries, serialization strategy, and integration regression.

1. Confirm ID form and length: distinguish auto-increment, UUID, Snowflake, and business numbers; estimate whether they exceed 16 digits. If unsure, treat them as possibly exceeding it.
2. Confirm contract boundaries: which APIs are external and which only use internal RPC; external JSON APIs should convert to strings first, while internal strongly typed RPC can keep numbers.
3. Apply a unified strategy at the serialization layer: affect only ID fields or specified types, avoiding conversion of amounts and quantities to strings. This step is a common failure point.
4. Documentation and integration regression: mark OpenAPI schema as string, sync front-end types, add oversized-value test cases, and check old client call volume.

Which APIs should convert to strings, and which can keep numbers?

Not all Long values need to be converted to strings. Judge by two points: whether the ID exceeds the safe integer, and whether there is a weakly typed environment among consumers. When both conditions are met, the string contract has clear benefits; when only one is met, weigh it by cost.

• Recommended to convert: external OpenAPI, H5, mini programs, JS SDK, cross-system JSON, distributed IDs, order numbers and serial numbers.
• No need to convert: pure internal RPC using Protobuf or Thrift where both sides parse with 64-bit integers; auto-increment IDs in small tables that predictably will not exceed 16 digits; APIs not directly consumed by the front end.
• Boundary sentence: as long as there is one weakly typed consumer, the ID should be designed with a string contract; if all consumers are strongly typed servers parsing with 64-bit integers, keeping numbers can save one type conversion.

Common questions

An order ID's trailing digits become 0 on the front end and refreshing does not restore them. Is it a cache issue?

No, it is usually JSON number precision loss. The back end returns a Long number, the browser has already rounded it during parsing, and refreshing still reads an inaccurate value. Changing serialization is what fixes it.

Does converting Long to string on the back end affect database storage and sorting?

It does not affect database storage; fields are still stored as bigint, and database-side sorting works as usual. When the front end sorts strings, lexicographic order of numeric strings may differ from numeric order, so it needs numeric conversion or a separate sort field from the back end.

Can we just use BigInt parsing on the front end without changing the back end?

It is feasible when consumers are controllable, but every client must switch parsing methods, and the value must not pass through any intermediary layer that converts to Number. Third-party SDKs or mini program environments may not support it, and integration cost may be higher.

Do ordinary auto-increment primary keys also need to be converted to strings?

No one-size-fits-all rule. Auto-increment primary keys that predictably do not exceed 16 digits can keep numbers; distributed IDs, Snowflake IDs, and business order numbers that may exceed the safe integer should be returned with a string contract.

If a live API changes its return type, will old clients break?

There is compatibility risk. When old clients parse as numbers, receiving a string may cause a type error or be treated as 0. The experienced approach is to add a version or switch and phase out old versions gradually based on call volume.

Applicable scenarios and non-applicable boundaries

Suitable for external OpenAPI, multi-language consumers, and distributed ID scenarios; a common 2026 practice is to make the ID type clear during API contract review rather than waiting until integration reveals trailing zeros and then reworking. Not applicable to pure internal service-to-service RPC where both sides parse with 64-bit integers, IDs are short and predictably do not exceed 16 digits, and the front end does not consume them directly.

Boundary sentence: if the API is called only between servers and both sides parse with 64-bit integers, it can keep numbers; as long as there is one JS weakly typed consumer, the ID should be treated as a string contract. You can check whether the ID type is clearly defined against the ECMAScript safe integer range or your own API acceptance checklist.

If you are designing an external API, first mark the ID as string in the design document, then decide the serialization strategy; if it is already live, first count consumers and ID lengths, and transition by version rather than directly changing the old API contract. For pure internal service-to-service calls where both sides parse with 64-bit integers, numbers can be maintained without forced refactoring.