I want to compare developer or client registration page on several developer portals with the aim to show what makes it easier for developers. Let us say that there are companies that provide APIs for integration with their service such as Apple, UrbanAirShip etc. On the developer portal, there are usually steps marked 1,2 and 3 to get the developer from start to finish with the client. Now different companies may choose different groupings of their documentation but the workflow a developer expects is how to build the app, how to connect to the various services, and how to deploy or submit for public use. In all these there are usually read only documentation. And they need not require sign-in.  The signin is required only for the registration page where we issue apikeys or submit the application for approval. The registration to get the api keys and the submission are nearly the start and finish of the developer engagement. The documentation itself could be made public but this is a choice for the company. The main thing is that the developer may exchange information on the registration page such as redirect URI and apikeys that will matter to the application being developed and the easier we make it for the application to be developed with less time spent diagnosing the issues the better. I want to call out the issues we face when writing applications. First, there has to be a mention of a basic call sequence or sample code for the login page. This lets the developer try out the code the same way as it was used internally. Besides, it gives something to the developer to work with.  Second, there has to be categorization of API resources for the developer to pick and choose from. This categorization should reflect the capabilities of the API rather than the variations found in the API. Next in each such category, there has to be some API picked out with proper requests and responses. The parameters and responses often help expedite development because it shows how the calls are made. They also give an indication of the objects to be mapped on the client side. What would be ideal is if the classes or models corresponding to each API request and response were made available to developers to download. They need not be available as nuget feeds though that would be great but make it available  so that the developer doesn't have to guess the classes from the request or response. These assemblies  in the nuget packages don't have any logic just some classes with their object model for developers to serialized or seserialize their requests and responses. Next, the apikeys issued should be immediately usable instead if waiting for approval. If the apikeys do not immediately yield the responses as mentioned in the API documentation, this lets down the development enthusiasm. Lastly, there should be proper error messages in addition to error codes from each API so that the caller knows the corrective action to take. The error messages go a long way to facilitate rapid development