Our application is a pure backend server. Serving JSON APIs to the users.
Users will be calling these APIs from their backend in 99.99% of the cases.
...
It does not matter what the API is serving or how the user is supposed to call the API. Attackers don't care about how something is supposed to be used but typically rely on not intended functionality.
If authentication credentials are automatically sent and no cross-origin detection or protection is done, then an authenticated client can be tricked into making in authenticated requests controlled by the attacker.
Authentication credentials are automatically sent with cross-origin requests when basic authentication is used or cookies - although many modern browsers nowadays limit the problem by making cookies same-site by default. Other automatically sent authentication methods are client certificates or Kerberos resp. NTLM tickets.
If the attacker can induce the client to make such a request then the attacker does not need to actually know the authentication information - the client will add these by its own to the request.
Sometimes "authentication" does not rely on specific credentials but simply allows anything which comes from specific IP addresses or network. While a cross-origin request is triggered from "outside" it is using the clients browser to actually do the requests which thus comes from "inside" and is treated as authenticated.
If the API instead relies on something like an authentication token which explicitly needs to be added to each request, then the attacker would need to know the authentication credentials and cannot blindly trigger an authenticated request. In this case CSRF would not be doable.
Similar if the API requires requests which are not simple for example by requiring special HTTP headers, then CSRF can not be done unless the site employs a weak (non-default) CORS setup.
can we go ahead and mark this flaw as false positive?
Too few is known about your actual API to decide on this.