Right and wrong in this case are values questions and therefor utterly unanswerable on an online forum. What we can speak to is the impact of this decision.
Largely, this is a question of what the team lead is looking to accomplish. If the hope is that by asking you to build API tests, the QA team becomes superfluous and can be skipped, the likely result is either disappointment (you're going through QA anyway) or production defects (if you skip QA). This is mostly because testers and developers are approaching the problem with two different mindsets. The developer is looking for a solution path while the tester is looking for edge- and negative-cases. That isn't to say that a developer can't shift their mindset, but the developer spends decades developing one mindset while the tester spends the same amount of time doing the other. This is complicated further if you are both the developer and the tester of the same code because your brain is anchored into the way you solved the problem - it's like testing with blinders on.
For simplicity's sake, let's say there are 4 types of errors we'll find in code: mistakes, logic errors, usability errors, and design flaws. If you are the developer who wrote it, building some unit or integration tests are likely to drive out many of the mistakes and some logic errors (but certainly not all as your test may suffer from the same ones). If you are not the developer who coded it, writing those tests will probably cover many mistakes, logic errors, and some design flaws. The QA engineer is likely to uncover mostly usability errors, design flaws, an a few logic errors and mistakes.
When I look at the distribution, what I would best like is for a developer and tester to work together. However, I definitely see that I cannot replace QA with a developer testing. Therefor, whether the ask on you is right or wrong largely depends on what happens in addition to you testing the API.