so do I need to still consider this as a vulnerability?
It depends on the details that you have not shared with us. I often have a hard time with raising XSS tickets against APIs because, by definition, an API is returning data and it's the browser / client / javascript that is choosing to execute the API response as code, in which case I would raise a "data-vs-code confusion" ticket against the web client. But in some cases it is the API's fault.
Example where it's the API's fault
If the API is returning HTML content like this:
HTTP/1.1 400 Bad Request
...
Content-Type: text/html
...
<HTML>
...
You submitted:
"<script>alert(0)</script>"
</HTML>
Then that's clearly the API's fault because the browser has no way to know that <script>alert(0)</script> was meant to be text and not code.
However,
Example where it's not the API's fault
If the API is clearly returning data, for example:
HTTP/1.1 400 Bad Request
...
Content-Type: application/json
...
{"errmsg": "You submitted: \"<script>alert(0)</script>\""}
then that's fine because the API is clearly marking this as data, and the javascript client would need to do something very very wrong for that script to get executed.
Summary
If I were you, I would keep digging until you can actually trigger a script alert popup, and then decide whether it's the API or the UI that's at fault.
Just to comment on @fmgp's answer: I agree that self-XSS is technically not a vulnerability, it's still sloppy coding practice and should still be pointed out and fixed. For example, that code may get copied into somewhere that is actually dangerous, or an attacker may find a way to trigger that code via a phishing link, commonly by exploiting frameworks that automatically promote GETs with URL params into a POST when there is no GET handler.
