while the main logic is perserved toghether with API specification
for example it doesn’t make sense to me to have my pre and post JS scripts and assertions added to some scenario step where I would have to make sure it’s not deleted or the be reused etc. instead of just using it from Cases and maintaining it there.
But one can argue that like “APIs tab is for Devs and Test tab is for QA” so I would then just have smaller scenarios with JS scripts that would be re-used in a bigger scenarios and maintained only in 1 place but that kinda doesn’t go well in my brain organization 
it’s more of a dilemma “where do you plan to capture your functional checks logic” - APis cases or Test/Test Scenario steps
For now the “import from endpoing cases” as a reference works best for my needs, the only problem there is you are not able to check the values at glance for each step before you run your scenario
so you have to either go to edit or just run it and then check Actual Request tab 
Which is fine for me I guess, only a few more actions
I completely understand your situation, and our suggested approach is to use endpoint cases for regression testing of individual endpoints (We will optimize related functionalities in the future, such as batch run cases and viewing request values in test steps directly, etc). For simulation testing of business scenarios, use test scenarios, as they can include process information.
Understood
tnx again 
this makes complete sense when I think about it now
so the cases are for isolated API testing
test scenarios for simulating user and having multiple endpoints involved
love it!
I think it clicked in my head now
Thank you very much for your detailed feedback and suggestions, Svike, which can help us make the product better.
You are welcome
Keep on working on this amazing app
I will spread the word to my colleagues about this awesome Postman alternative