OAuth2 - Authorize with no user interaction
The Oauth 2 grant flow that you're describing is the Authorization Code Grant Flow, like NtFreX's answer says. And like they say, if you have the option of using one of the above two grants with that API, that's the easiest solution.
However, if you don't, there's still a way to avoid "user interaction". It's unclear what you mean by "user interaction", but in the Authorization Code flow, that usually means logging into a web app that calls the API you are trying to authenticate into, and then consenting on the consent page. See https://dev.fitbit.com/docs/oauth2/#authorization-page for an example (I implemented OAuth 2 for Fitbit :)). You'll need to use an automated web browser like Selenium to click the consent button. Then you can capture the code in the response from /authorize and send the code to the access token endpoint.
The oauth2 grant you are describing is called Authorization Code Grant. This way of authentication has been designed so that applications which want to access resources of a user do not have access to the users credentials.
So if you found a way to interact with the user credentials in this grant it would be considered a hack.
If you do not want the individual user to enter the username and password but you want to access the api with a kind of "system account" this is not the oauth grant you should use.
There are multiple grants that would work for you. The question is which are supported by the authorization server and available to you.
Resource Owner Password Credentials Grant
This grant type is suitable for clients capable of obtaining the resource owner's credentials.
However
The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application.
It is very likely that this grant type is not avaiable as it could be misused to steal user credentials.
Client credential grant
The client can request an access token using only its client credentials.
How the resources are tied to a client is not part of the oauth specification and therefore provider specific.
If you want to read more about oauth2 here is a good article.