I'll bet there's a command somewhere in the API backend code that simply assigns a variable to whatever is found after "&key=". Whatever language they wrote it in, the variable assignment is interpreted with that language's rules for deciding if it's a number or a string. So there's probably a statement something like this in the code:

finalKey = parsedKeyString

The fact that it allows the variable "finalKey" to freely transmute between an integer and a string means that the API backend is written in some sort of scripting language with dynamic typing, rather than a compiled language with static typing. It's a bug where the programmer assumed that it would always stay a string, and they forgot that their language is dynamically typed.

You know, I'm going to say so in the bug report, because the guy responding to the bug report is trying to tell me that the doublequotes are required by the API (they're clearly not) and I think they might be planning to close the bug as Won't Fix.