How to structure your full system integration tests?

What is a good practice to structure full scale integration tests towards a REST API? (Top of the testing pyramid)

I am running a system with several micro services with one external facing REST API. I want to write integration tests for this API. I am choosing between 2 strategies of test organisation.

Strategy 1 Isolate your test subject as much as possible. This is what for example the UI interation test framework cypress recommend. It could be applicable in API integration tests as well. This would mean that when writing tests you would use some sort of builder approach, where you define the state of your application before the test starts. For example when testing that it is possible to delete a user:

1. Set up an access token
2. Create a user These steps could be done by using a Builder API or directly accessing the Database. The tests would then be described like DELETE /users/:id should delete the user This technique would separate your tests nicely, but would not mimic how real users would use your product.

Strategy 2 Build your tests as stories. This would mean that you are looking at your system from a consumers perspective, and a test would look like Example test: A user can delete them selves So, as a consumer, to delete a user, you would then have to Create a user, and to create a user your first need to Create an access token etc. When you have done that, you can call the endpoint of interest and delete the user. So included in the Delete user journey is also create access token, and create user. This will cause alot of intertwined tests, but be more in line with how the actual consumers are using your API.

Which one is "best practice"? Or is there another approach that I should consider?