API Keys for users.

From experience I know users are not going to want to give up their username/password to third party sites using your service. Might I suggest instead of using the username/password in the soap call you use an API key of some sorts that is mapped to a particular user.


Ryan, Thanks for the


Thanks for the comment.

The service allows registration of multiple users under a single account. So, a developer might have one username/password combination running in "development mode", while the main account holder can have a separate username/password combination for the live app in "production mode".

This way, no credentials need to be shared outside the organization. Does this cover the use case you were referring to?

Further to Adam's reply. The

Further to Adam's reply. The account administrator may add new users to the account, close them, and change both their password AND usernames. We have thought about providing authentication keys but could not find the benefit over changeable username and passwords. Can you please explain why would it be better to use keys?

Username/password pair is OK

Username/password pair is OK but I think API key is better

API key means a remote user is authenticated to use some of your services, he might not registered to your system.

While username often represent a REAL person in your system, besides the services like SendLetter he can use in the system, he also can change his password, modify his profile, etc.

Take google maps API for example, you do not have to get a google account for use the service, just get a API key, nest it in your page, and there you go, everything is OK. This makes the use of the API easy.