Thanks for trying to support me here.
In fact, what I am trying to do is to create a unittest code including a profile that has been merged, trying to test the case when a profile is merged an dissapears pointing our to another profile.
My unittest library is quite extensive, and I am quite sure the way I am using ID is the correct one. Also all the other tests works but this one.
In particular, what I did for my testing is to merge the profile "MERGED"
https://sandbox.geni.com/people/Sister-Profile/13259711
into the profile "ORIGINAL", which remains
Private
If you go into the sandbox to "ORIGINAL" it looks a normal profile, if you go to "MERGED" you will receive the usual message that it has been merged.
So, what I tried to do is to call both profiles with the API:
"MERGED"
https://sandbox.geni.com/api/profile-g13259711?access_token=MY_TOKEN
"ORIGINAL":
https://sandbox.geni.com/api/profile-g1150209?access_token=MY_TOKEN
So, using the API, "MERGED" fails with an SSL error but "ORIGINAL" works.
So, if "ORIGINAL" works, that means that the problem is not the "g", as well, it proves that the root certificates are ok, as working for "ORIGINAL".
That's why I think that there is likely a bug in the server code.
More explicitly, if you are authenticated in your browser and use that authentication to use the API so, I introduce in my browser the following:
"MERGED"
https://sandbox.geni.com/api/profile-g13259711
"ORIGINAL"
https://sandbox.geni.com/api/profile-g1150209
Both of them work! (which discards also the "g" issue). So the problem is specific to the authentication method that I am using.
Actually, the output from "MERGED" is what I am looking for. The key "merged_into" is telling me the new profile it is linked (in API id)
Btw... I have always struggled to understand the software design principle to store 2 different ID for profiles....
Thanks again.