I usually do the same thing. Both the 32-bit issue (that issue being with JSON libraries, not the spec) but also: IDs are opaque tokens. If down the road it makes sense to use UUIDs or have a sharding hash or something else, you don't want clients tied to expecting an integer datatype.

I feel like a lot of people will see that an just cast it to an int however.

That could happen but in a lot of strictly typed languages it would be non-obvious and special effort to do so.

There's absolutely no justification to send ints when you have any reasonable chance of needing to change it to a string later. Besides, IDs in a public API fundamentally are not numbers. You don't add them, subtract them, multiply them, shift them, inspect any property of them besides equality, or anything. They're opaque tokens used to identify things with the server.

What if the integer exceeds the maximum allowed on 32 bit machines and you try to decode the JSON?

That has nothing to do with JSON, which allows numbers of arbitrary size.

This is mostly just a typo in the examples I put, but I will consider using only strings for this type of stuff, to avoid issues.

Given the dataset you have to serve, I don't think you'll be having any issues if most of the JSON parsers give you 32bit integers.