A quick google search revealed QTP as a GUI robot. Such tools are black box testing tools, testing the compiled binary of the application simulating a user pressing buttons, entering values in some fields, checking the results shown at some other fields etc. Typically, you don't have to know in which programming language the original program was written. Creating such tests typically only makes sense after the GUI parts have reached some level of stability.
When talking of API level tests (as opposed to GUI robot tests), we are talking about white box tests of the GUI logic, not through the GUI elements itself, but through an API layer of the application which is very "close beneath the GUI". Such an API layer is most easily created by applying the "Model-View-Presenter" pattern. This pattern allows testing in a presenter-first approach, which makes it possible to create automatic (unit) tests very early - when doing TDD, earlier than the code for the GUI logic itself. Those tests are typically written by the developers who are writing the presenter, in the same language as the tested application itself, and you typically need only something like a free xUnit testing tool, not more.
To my experience, both kind of testing approaches can test different things. But both approaches can also be used to test a lot of overlapping requirements, in case where I would clearly prefer API level tests (my former experiences with GUI robots were, lets say, a bit disappointing, too much effort for too less benefit). But your mileage will vary.
Concerning Scrum: I have never done that, but I suspect tests using a GUI robot tool are best written after each sprint, while API level tests should be part of the development during the sprint.