We are not able to understand the use case of validating the request_token from the profile call. We will look into the possibility of adding the `client_id` field in the user profile call. But, maybe you can map user_id with access_token, user_name, email_id, etc available from the user access_token session generation which are available too in the user-profile call and keep validating at your end for all further requirements.
Use case: We added a new 'Login' Overload in our library which takes access_token and client_id as arguments. Users who have already logged-in and generated access_token in another program/computer can simply pass that access_token in our library instead of full login flow. In our new 'Login' method, we just want to make sure that the access_token is valid and the client_id arg matches with the client_id received in user-profile response before the user making any other API calls.
Another problem is, our library can't identify the client if he just logins with access_token and api_key. Responses of positions/margins/holdings doesn't contain client_id. Only Order history has client_id, but this will not reliable as it will fail if the order book is empty and also we can't place a test order just to get cleint_id.
We will look into the possibility of adding the `client_id` field in the user profile call. But, maybe you can map user_id with access_token, user_name, email_id, etc available from the user access_token session generation which are available too in the user-profile call and keep validating at your end for all further requirements.
typo access_token*
Use case:
We added a new 'Login' Overload in our library which takes access_token and client_id as arguments. Users who have already logged-in and generated access_token in another program/computer can simply pass that access_token in our library instead of full login flow. In our new 'Login' method, we just want to make sure that the access_token is valid and the client_id arg matches with the client_id received in user-profile response before the user making any other API calls.
Another problem is, our library can't identify the client if he just logins with access_token and api_key.
Responses of positions/margins/holdings doesn't contain client_id.
Only Order history has client_id, but this will not reliable as it will fail if the order book is empty and also we can't place a test order just to get cleint_id.
client_id is already being sent in the profile response. The response is not updated in the docs. We will update the doc soon.