We’re having difficulty realizing the full potential of using an API to provision the Omada Cloud Controller.

We’ve already created the Cloud Controller, added sites, and assigned devices to a few of the sites. There are a few administrative and user accounts, and all functionality exists on the online controller. Our next step is to incorporate API commands to automate some processes of deploying equipment.

The snag exists in attempting any command that requires the “login” permission.

While Using Postman, and within the Postman guide, it mentions to perform the login API Command, this will generate a Token.  That token is then added to the Parameters. This updates the Headers, and applies the Cookie as an Auto-Generated Header.  So far, on track.

This is where we feel we are missing a crucial step.

For example, while testing out the API to Get the Dashboard Tab List.  The above process is completed – after the token is generated, added to the Parameters tab and the Headers tab is checked to verify the cookie has been added - the Method is then changed to GET, then modify the domain.

Using the guide – at this point I modify the existing -
https://use1-api-omada-controller.tplinkcloud.com/{Omada_Cloud_ID}/api/v2/login?token={Generated_Session_Token}

To instead use the following API -
https://use1-api-omada-controller.tplinkcloud.com/{Omada_Cloud_ID}/api/v2/sites/Default/dashboard/allTabs?token={Generated_Session_Token}

This returns a 404 error:
{

    "timestamp": 1678715967902,

    "status": 404,

    "error": "Not Found",

    "path": "/{Omada_Cloud_ID}/login"

}

Would anyone have any insight or documentation that can illuminate what we are missing in this process?