FAQ

We don't support the OpenSocial RESTful / Data API, but we do have our own Hyves API with many useful features. This cannot not be used directly in OpenSocial gadgets. You will have to use your own backend to connect to our API. More information can be found here.

If you receive an error, first check in the list on http://developers-hyves.nl/errors on what possible causes en solutions are for this error. Hopefully those descriptions should put you on your way to the solution.

This means your own server-time is not set correctly or is not syncing properly. See http://developers-hyves.nl/documentation/data-api/oauth-parameters-hyves....

Especially errors with calculation of secrets, should benefit from the descriptions of http://developers-hyves.nl/documentation/data-api/content-encoding. If you have problems with secrets, please check our http://developers-hyves.nl/documentation/data-api/oauth-example-code, and see if your code behaves the same way for each example. The examples were taken from http://wiki.oauth.net/TestCases, and most of them serve as unit tests for us.

Another problem that we encountered, is that PHP (or the browser?) translates http://data.hyves-api.nl to http://data.hyves-api.nl/ (note the final slash). If the Consumer calculates the oauth_secret on the basis of an URI without the final slash, and the Service Provider does include the final slash, the secrets will not match. So make sure that you always have your URI end in a slash.

You can use debugging oauth signature calculation.

All IDs (userid, mediaid, etc) are the same for every Partner. In the past we provided different IDs for each partner, so maybe you still have to convert your IDs if you are such a partner. you will find this link on http://www.hyves.nl/api/manage/

IDs are an 8 byte (64bit) integer, encoded as a hexadecimal string of 16 characters, which means they can be stored internally as 64bit unsigned integers. There is a possibility that we are going to need longer IDs in the (far) future, but such a move will be announced long in advance. Although the IDs can be saved as 64bit integers, we expect the IDs returned to us to be the exact same as we supplied them to you - as a 16-character hexadecimal string; this especially means that "low numbers" should be pre-padded with zeros to be 16 charachters long. If IDs of any other format are received, they will be treated as non-existing IDs.

Something else should be mentioned about IDs: For many objects, for instance media, having the ID enables you to see the object. There is no extra check for security, so it is to the Consumer to make sure that ids retrieved as one user are not automatically shown to another user. See the http://developers-hyves.nl/returnvalues for more information.

Note: sometimes no id is returned (the field is empty). In this case, no foreign relation is present, or you have insufficient rights to see the id. An example is the userid for the default profile image.

The Hyves API allows you to use usernames to retrieve a user. It should be noted that usernames should not be used for anything else. Unlike most websites, Hyves allows users to change their usernames; and they do so regularly. So it would be an especially bad idea to use usernames as primary key for anything; the user with username "john" today, may not be the same as the user with the username "john" tomorrow.

On the Hyves website, the username is not displayed anywhere, except in the URL for the personal overview page. That is why there is no API function to retrieve the username for a user. Although the username can at the moment be deducted from the "url" field of a user, the format of that link may change without notice.

Our image serving system works in such a way that media urls can only be guaranteed for a short period. We suggest caching of media urls for not more than one day.

Contact information (e.g. email addresses, phone numbers) will not be available through the API anytime soon. The idea behind this is that there is a huge difference between allowing my friends to see my email address, and allowing applications logged in as my friends to see my email address. I don't trust my friends to be able to decide which applications they trust with my information.

Looking at it from another way: like the rest of the world I receive a lot of spam. This is because my email address was harvested once by a virus on a computer of one of my friends. So again, if I have friends that manage to install virusses on their own PCs, I'm not going to trust them to only allow benevolent applications to see my email address.

Last part of my argument is that in general contact data is needed to contact people. Even applications with the most benevolent intentions can send emails that are perceived spammy by users (I'm sure you've received your fair share of email that was probably sent with the best intentions, but that you really didn't want to receive). So we don't see how we can share contact data while at the same time protecting our users against spam.

If you want contact information on the logged in member, the best way is to just ask them for their email address. I'm sure if they're willing to share that, they won;t mind typing it in.

This problem can occur if the client reuses the same socket and sends another stream to Hyves XMPP server.
The Hyves XMPP server only accepts connections once per socket/stream

The solution would be to use a new socket for every new stream. If a new socket is created then it would be possible to reuse the same resource.
It is strongly advised to NOT create multiple resources as it may result in unwanted behavior as it may cause problems with routing on the server.