There is no "correct" answer here. It's really about finding the tradeoffs you're happy with.
Sharing one model across layers trades coupling for development speed. It will allow you to get your code working faster, but it inherently couples all your layers together. A change to the model in the Service layer will affect the models the API consumer sees.
On the other hand, having dedicated models for each layer increases development time, but decouples your layers. If you make a change to a model in the Service layer it doesn't automatically trickle over into the other layers. This reduces the risk of inadvertently breaking things in other layers or inadvertently leaking unnecessary information to API consumers or the database.
The downside here is, as mentioned before, the additional upfront development cost, as well as the additional cost required when the model changes actually do need to apply to other layers.
So, you're trading between loose coupling and speed of development.
Does every layer need to have it's own business object representation?
No, it doesn't need to.
If you value speed of development over maintenance costs then sharing a model across layers is a good choice.
On the other hand, most software project's costs are in the maintenance phases. So organising your code to make maintenance easier could save you time/money in the long term.
Should every layer have its own business object representation?
The answer really depends on what your optimising for.