Access to our API is based on user name and password combinations, linked to a single account. They are further linked to a server IP address. An account can also have multiple user names and passwords. Accordingly, if you administer multiple accounts with us, you should request log-in information for each account.

For backwards compatibility, all commands can accept the username and password in the request. However, for a number of reasons, this API introduces a new security model which all users are encouraged to use. Username/Password support will be withdrawn once a critical mass of customers are using the new method.

In the new model, the ‘password’ is never ever transmitted in a request. Instead a request (AUTH) is sent from an authorised IP address containing the user name and a key. Specifics of the key are described in the command reference below but it is essentially the hash of the password and certain other dynamic data. It should therefore be unique between/amongst customers and of little use if obtained. This request yields a ‘token’ which is rather like a session id. It is used in every subsequent request from a specific client IP address for a defined period of time. The intention is that a customer application could give time limited access to a remote application running on a different IP address. 

Please note though, this token still allows full read and write access to an account from the specified client IP address and should be treated with appropriate caution. 

Finally, we allow the authorised server to destroy a token prematurely thus maintaining full control of the remote access.