Possible to lift discrepancies between Portal/API users
-
Would it be possible to not have 2 separate users for Portal and API?
It is confusing to me to have “some” magic but not all:
- Devices added are visible for both
- But subscriptions are separate
- The application added through portal will NOT be subscribed to devices added through API
- The application added through API seems tp be subscribed to devices added through portal (or is it?)
- It’s not possible to verify through portal what you did through API
Being a platform for creators this seems cumbersome to me. I’m unaware of the benefits of this separation so probably I’m missing some needed insights. But maybe it is architected this way from a vision which is no longer applicable?
Is it possible to explain the reasoning behind this separation and indicate if this is something that might (not) change in the (near) future?
Thanks
-
Hi @magnatron,
I agree this can be a bit confusing, but this is currently necessary for the portal to work correctly.
Devices added are visible for both
^ This is correct; devices belong to a project and both users belong to the same project.
The application added through portal will NOT be subscribed to devices added through API
^ This a bug and we are working on a fix for this
The application added through API seems tp be subscribed to devices added through portal (or is it?)
^ as far as I know only the subscription of the portal is updated, not your own subscriptions
It’s not possible to verify through portal what you did through API
^ this is correct. As the api provides a lower level access with more flexibility, it is currently not possible to show what you did in the portal.
Most of these issues you can workaround by using the mysubscriptions endpoint you will only see the subscriptions of your own user; not the portal user.
The reasoning behind the different functionality in the api / portal was to have an option for users needing more functionality than offered by the portal (ie: multiple endpoints) by giving them access to the underlying api … downside is the complexity of it.
Ideally the portal should cover all the functionality and we have and we can add an high level api so you can automate all the actions you do in the portal. So if you have any suggestions on what functionality is missing that you need the api for, let us know your use-case so we can see if that is a good fit for integration in the portal.
