Hey @jokull,
I see, thank you for explaining! That does indeed happen if you provide altogether invalid IDs (like if a bot were just scanning for them and making up IDs).
First, I should probably point out that it’s not a great idea to have your page routing directly tied to API lookups, if for no other reason than that this would make for easy denial-of-service attacks from any bot going to your pages (existent or not). You would then have to pay for all their pointless API calls 
It would be safer to route only to pages (IDs) you know you’ve created and to 404 or redirect other ones by default, unless you are specifically trying to dynamically generate pages for SEO or such.
That said, if you really want to do this, you can add a check to your router to first test to see if the ID is a valid Dato ID before you make the API call. To do that, you can import the isValidId() method from our JS client lib (or just copy and paste that file into your script): https://github.com/datocms/js-rest-api-clients/blob/main/packages/cma-client/src/utilities/id.ts#L34-L71
That will test the ID for validity so you don’t pass it on to the API if it’s junk.
(Edit: The package has since been updated. The below comment is no longer relevant.)
(Outdated, please ignore): Click to expand: Only relevant if your Dato project still has number-only IDs
Side note: If your Dato project is really old, and not using alphanumeric IDs yet (i.e., it still has integer IDs from our past), you can also allow through 6-byte integer IDs (i.e., ints <= 281474976710655). That check is NOT present in the isValidId() option but IS in the GraphQL layer, which is why integer IDs still work there. Newer projects don’t have to worry about this at all.
Does that help?