[RussianCow]

I think the most important thing is to be consistent, instead of having a mix of API logic that originates from components and from the store. And since there are certain types of higher-level logic that are very difficult to house inside components, I have found that having your store be the origin for _all_ API-related logic is the best way to go, even if it seems overkill for simple things. It's better to be globally consistent than to try to have the simplest solution for every individual case.

(Disclaimer: I use React/Redux and not Vue/Vuex, but I think the above applies equally to both.)

[parr0t]

This is essentially my chain of thought and what I have done. Even if it is a simple request that is confined to a single component when a developer looks at the codebase they can know that all API calls are called from Vuex modules and not modules _and_ components.

That then leads me to my next question though, if I am using Vuex to abstract the API calls is it bad practice to use Vuex actions for API calls that don't need to be saved into the store?

[RussianCow]

I don't think it's bad at all to have an action trigger an API call that doesn't save anything to the store. However, as @mmcnl said in response to your original comment, you probably want to abstract the actual API-related code into its own module, so that you don't implement the API calls in the actions; then your actions become thin functions that simply call that code with the necessary parameters.