# Introduction

If you have used WADE App and inspected Browser Sessions tab, then you have probably seen that these sessions consist of 5 steps:

%%{init: { 'theme': 'base' } }%%
flowchart LR
    A(1. Start profile) --> B(2. Download folder)
    B --> C(3. Start browser)
    C --> D(4. Upload folder)
    D --> E(5. Stop profile)

These steps will be explained in details further in this guide.

If you have used alternatives, then you already know that their flow looks similar, except one important thing - they group most of the steps into one, disallowing you to control the execution for the sake of simplicity:

%%{init: { 'theme': 'base' } }%%
flowchart LR
    b0(Your code)
    b5(Your code)
    subgraph Alternatives do not allow you to control these steps
        b1(Start)
        b3(Download folder)
        b4(Browser opened)
        b1-->b3-->b4
    end
    b0-->b1
    b4-->b5

What's even more, they do not allow you to control the browser stop either:

%%{init: { 'theme': 'base' } }%%
flowchart LR
    b0(Your code)
    b4(Your code)
    subgraph Alternatives do not allow you to control these steps
        b1(Browser closed)
        b2(Upload folder)
        b3(Delete folder)
        b1-->b2-->b3
    end
    b0-->b1
    b3-->b4

We treat this as a bad design decision, as you are unable to inspect or modify profile folder before the browser opens, as well as after the browser is closed.

Unlike alternatives, we decided to separate every operation so that you are the one responsible for all of these steps, and we did it for the two main reasons:

1. Now you have full control over each step, which allows you to fine tune them to fit your use case in the most efficient way. With our approach, you are actually encouraged to:

   • Read or change cookies before and after the browser launch
   • Skip folder download or upload (you can store folders locally or anywhere else)
   • Load your extensions by placing it into the profile folder (no API needed)
   • Launch browser with custom command-line switches
     
     

2. Now it is more transparent which step has finished with an error in case of a launch failure. Have you ever experienced that alternatives just respond with 400 Bad Request or 500 Internal Server Error and provide no information on what has gone wrong?

   We designed our API in such a way that if any step ends with an error - you get a self-explanatory response. All the error codes are documented, and you almost always get an error message with a description of why the step has failed.