/igg/login
This request can be used for both login and for requesting golfer data. It will return a set of user records that match the login parameters. With the amount of golfers that are entered and maintained at the various golfcourses and ikgagolfen.nl it is very hard to keep each client in the database unique. Therefor, logging in, will not always produce just 1 matching record. For instance: A golfer is registered 3 times and the login parameters name, initials, birthdate and phone number are provided. This may result in 2 records because the phone nr of 1 of the 3 registrations was entered wrong. Of course the security level is very low if you login like this. The security level is returned in the resultset and your application should act according to this security level. For instance: Do not allow the user to set a new password if the securitylevel is 7 or lower.
security level:
| 1,2,3 | very low, only for retrieving a list of users / double registrations |
| 4 | booking new teetime reservations allowed |
| 5 | showing, changing, cancelling existing teetime reservations, booking, showing, cancelling lessons |
| 6 | changing email address (old address will receive notification), setting a new password if no password is present for this client yet |
| 7 | changing handicap, editting friends lists |
| 8,9,10 | changing password (this level can only be achieved by logging in with password) |
parameters:
| auth | the authorisation code you received from Intogolf BV (mandatory) |
| pwd | client password (mandatory) or authHash |
| relnr | client id |
| email address | |
| name | last name (without van der) |
| ngf | dutch official golfer id (typically a 6 or 7 digit number) |
| gpp | dutch official golfpassport id |
| getoldstylesessionid | if 1 you will receive a session id en checksum in the resultset. These values can be used to pass to the old style ikgagolfen iframes as &sid=<sessionid>&q=<checksum> |
You can provide any combination of parameters. The best results will be:
- relnr and pwd
- email and pwd
- name and pwd
(warning: eventhough the securitylevel of these combinations will be very high, it is still no guarantee for a result set of 1 record only, because people may have double registrations with the same password)
When you have an authHash value for a client you can supply the authHash value in the pwd field. In this case the relnr field is mandatory. You can retrieve the clients authHash by loggin in as described above or with /igg/addrelation.
Please note that a relnr may become invalid at some point in time due to merging double accounts or deleting accounts.
Example: https://backend.ikgagolfen.nl/igg/login?auth=<your authrisation code here>&email=richard@intogolf.com&pwd=golf
result:
{
"login": [
{
"relnr": 602234,
"name": "R.J.W. Knol",
"lastname": "Knol",
"nameprefix": "",
"initials": "R.J.W.",
"firstname": "Richard",
"mv": 2,
"email": "richard@intogolf.com",
"phone": "243234523",
"phonemobile": "2423423423",
"datebirth": "19650225",
"golferid": "700712",
"gppid": "",
"privacy": 0,
"securitylevel": 9,
"relkey": "68de29c0547a5c23ad51f62154d1177c",
"authHash": "8c3a492b9bd0740d702a88c5776f8762"
}
]
}
The resultset attributes are self-explanatory except for:
| mv | the gender |
| golferid | corresponds to the parameter “ngf” |
| relkey | This hash key needs to be stored and is later on needed when you want to retrieve any personal data for the golfer. Beware that the combination relnr and relkey will not be valid forever. A user account can be deleted or merged to prevent doubles, in which case the relnr and relkey will become invalid. If you use an invalid relkey or a valid relkey in combination with a deleted relnr 401: Unauthorized will be returned when you try to use the relnr + relkey ombination in one of the other API functions |
| privacy | if 1, the user has checked a box indicating that he does not want his name to appear in search lists on other user’s sessions. For instance: you can not select them as co player unless they are in your friends lists. You can not add them to your friends list either, because they are not visible when you search for them. Your application will need to respect this. People with privacy set to 1 wil only appear in your result list if the securitylevel is at least 8, which means that he logged in with his password. |
| sid | if getoldstylesessionid=1 you will receive a session id to pass to the old style ikgagolfen iframes as &sid=<sessionid>&q=<checksum> |
| q | if getoldstylesessionid=1 you will receive a checksum with the session to pass to the old style ikgagolfen iframes as &sid=<sessionid>&q=<checksum> |
If a wrong authorisation code is provided, the backend will return “no authorisation”
