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.
I suggest you investigate oAuth instead of rolling something yourself. That's how Google, Facebook, and Twitter solve this problem. Pick whichever version suits your needs,
Out of all of these, I've always found the HMAC hashed request in OAuth 1 to make the most sense from a basic security point of view. The only concern being token refreshes.
But this would reduce the ease of use of the API, increase the latency because of round-trip and will not provide a better security. The fit is not very good.
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
Sounds like this is not an authentication but an identification protocol applied for a very limited API calls rate-limiting use case. While there are some question about this use case as well (e.g. it there is a DOS attack possible against legitimate clients if the secured_api_key is leaked), it might be practical and acceptable in some limited set of cases.
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.
If you want to validate a bearer token, multiple backends in different datacenters need to share a datastore that replicates at least somewhat fast. If you use HMAC-Signed URLS you just need to replicate the API keys that you use to calculate the token and the required guarantees are lower than for a bearer token. In principle, the method is sound - AWS uses a similar approach for signed URLs that allow access to S3 resources.
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.
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.