You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use identifier in a couple places when we talk about our API (and even in the API, such as here for the builder).
Practically the identifier is produced from the strings identifying the environment and tenant, and the API has been using these two separately and making the identifier inside the call. Would it make sense to accept either an identifier or an environment and userId in the SDK functions?
In my local version I have "deprecated" the environment+userId combination, but I don't see why we couldn't provide the flexibility to provide either here.
The text was updated successfully, but these errors were encountered:
My .02 is should we move away from specifying the environment in the identifier all together. Clients already work under the context of a single environment which could be derived from the environment token they use to authenticate
We use identifier in a couple places when we talk about our API (and even in the API, such as here for the builder).
Practically the identifier is produced from the strings identifying the environment and tenant, and the API has been using these two separately and making the identifier inside the call. Would it make sense to accept either an identifier or an environment and userId in the SDK functions?
In my local version I have "deprecated" the environment+userId combination, but I don't see why we couldn't provide the flexibility to provide either here.
The text was updated successfully, but these errors were encountered: