First thing needed to start working with API are properly designed file directory(ies). Note that with Unix APIs, files usually reside both in Unix and Windows environments. Well, this only looks trivial because in real life somebody needs to provide it to API users.
So, either installation script which is part of API distribution creates all needed directories, or this is done by sysadmin who provides all necessary access privileges. The latter option can easily take days and even weeks!
Next, we need simple working demos which show at least major API features. Once these demos start working, it is relatively easy to reengineer them into the proper project code. From the other side, demos verify that environment is set properly, so they are quite useful for system checking and testing.
Usually, both simple command line output and GUIs are insufficient to work with advanced backend APIs, especially when client-server connections are involved. So, quality API demos need to support logging.
Advanced app usually involves not just one, but multiple APIs, so it helps to keep materials on separate APIs separate to avoid confusion.
Third, complete API package needs to include a number of test data sets. Some of them can be hard coded, some come as ASCII, flat and XML files, some - as SQL statements.
When SQL engine is involved, we need to set up proper database(s) and check how API calls affect them. For this purpose, API package can include GUI utilities, but nothing can really replace full scale general purpose command line utility like Oracle's sqlplus and SQL GUI client. It is hard to imagine how to work with a database-driven API without these tools!
Fourth, we need a complete set of general purpose tools and utilities which are needed to work with API. These can be either directly included in the package - or it can be hyperlinks / Windows shortcuts to all proper download sites.
Last, but not least, there is to be a simple and effective way for API developer to support his users. Quite for some time, phone, fax and e-mail were used for this purpose, and now there are instant messengers. The problem is, with advanced APIs, we need to keep track of all that happens to numerous software and hardware components involved. In this situation, phone calls, instant messages and support tickets are not necessarily the best way to check what exactly scripts X,Y,Z do to database fields A,B,C in tables D,E,F.
In fact, generic solution for problems like this is well known, that's blogs and web forums. In fact, blog comments and responses to them act as traditional service tickets, but they are more versatile. The reason for this is that blog entries naturally have individual URLs which are equivalent to service ticket numbers. This means that all one needs to access a support blog entry is just to click on its URL!
Many blog and forum engines are available on the Net, both standard (Blogger, Typepad, Yahoo, MS and Google groups) and proprietary. It is hard to imagine quality API without such service.