You can't safely use SHA256 in that construction. The hash is simply the value of the SHA256 internal state after the last block. An attacker can take that hash and resume "hashing" from that point, adding additional data to the original data.
That attack is called "length extension", and it's the reason we have the HMAC construction. Here, I think you want the HMAC-SHA256 of the filter and user ID, with the API key as the HMAC key.
Time again and again and again: never ever implement your own crypto...
oauth is a good standard when used for the correct use case, which is not the case for this. Sometime a simple solution is better than a framework
The danger here is that the same protocol will be used for access control use cases for which it is not suitable (for a variety of reasons). A very good documentation (including thread modeling with attack vectors analysis) should be added to make sure this kind of mis-use does not occur. I would also change the title since it is too ambitious and misleading.
"Our backend checks if a query is legit by computing all the possible hashes using all your available API keys"
So why not just forget about the crypto (with all the risks of getting it wrong) and use an opaque bearer token?
I guess it's a question of where do you store application state - do it at the server and then you have to replicate the database that stores that state. Store session state at the client and pass it to the server means you can go to any data center at the potential risk of getting the security wrong.
I always thought there approach was interesting. Kudos for coming up with something very similar.