Currently v1 API users are capped at generating 2 API keys per account - I don't really see a logical reason why this cap is in place. I contacted support about it, and was told:
Unfortunately we cannot provision an additional set of v1 API keys after two have been generated. Earlier this year we made is so that all v1 API keys have an expiration date, and to facilitate a smoother transition between API keys, we also allowed for the generation of a second set. There should be no need to generate another set as the two API keys on your account are both currently valid and the API keys do not need to be unique per external integration that they are used for.
I think this misses the mark. Having expiring keys is great as long as you have a good UI for users to regenerate them. The ask for multiple keys isn't related to expiring credentials, it just basic security management for granulized access control, better logging visibility, and compliance to things like principles of least privilege when going through audits on things like SOC 2 Type1&2. The current config - being asked to make use of my 2 credentials and just share them across integration workflows would be a deficiently on any security audit.
If you were to reconsider this, especially given the fact endpoint access to different services is currently spread across 2 different versions - you could then start to integrate scope to your keys instead of the current global scope with filtering applied - which is also somewhat annoyingly permissive from a security point of view if you have multiple stores in your account.
