Keep large external JSON identifiers as strings

An external platform sends a numeric identifier larger than PHP's integer range. Decoding it as a float can lose precision, and converting that float back to text does not recover the original digits. Identifiers should be transported as strings where possible.

Preserve oversized numbers when decoding

<?php
$json = '{"id":1234567890123456789012345}';
$data = json_decode($json, true, 512, JSON_THROW_ON_ERROR | JSON_BIGINT_AS_STRING);
assert($data['id'] === '1234567890123456789012345');

JSON_BIGINT_AS_STRING helps with integers outside the native integer range. It does not force every ordinary JSON integer to become a string, so normalize the accepted identifier representation after validating the payload.

Keep the contract consistent across languages

A browser can also lose precision when a large identifier is represented as a JavaScript Number. Returning the value as a JSON string avoids asking every client to handle an oversized numeric value correctly. Store it in an appropriately sized textual column if it is an opaque provider ID.

Do not perform arithmetic on identifiers simply because they contain digits. Leading zeroes, future prefixes, or a provider migration can invalidate that assumption. Use your own database primary key separately when useful.

Test a short ID, an oversized ID, a string ID with leading zeroes, and an invalid object or array. Verify a complete round trip from incoming payload to storage to outgoing JSON. Comparing only a formatted display label can miss precision loss that later prevents a webhook from finding its matching record.

Reference

Official documentation. The examples here illustrate the stated boundary; adapt them to your application and test its failure paths.