Developer Experience
One of the most heard buzz terms in the online community is probably UX, or User Experience. This term encompasses all aspects of the end-user's interaction with the online service and includes practical, experiential, affective, meaningful and valuable aspects.
The same concept can be translated to the developer world, where it could be called Developer Experience (DX). In order to reach a big audience when publishing data it's very important to deliver as much convenience to the developer as possible.
"User Experience applied to developers, because developers are people too!" - http://developerexperience.org
API documentation is the first clue to your developer customer about the quality and usefulness of the API. When API documentation is complete and easy to understand, developers are probably more willing to continue their journey implementing it.
One important aspect here is the Time To First Successful Call (TTFSC). Being capable of doing a successful request to the API within a few minutes will increase the chances that the developer will stick to your API.
While documentation may be the most important aspect here, it can also help tremendously to provide clear code examples or SDKs (client libraries) for common languages and platforms to get the developer up & running. There are tools available, like Swagger Codegen or Apimatic, which can help you build & maintain client SDKs.
The last few years, a lot of standards have been developed in the API community. The most important benefit of leveraging standards is the ecosystem that has been built around these standards.
Swagger is a way to describe your API by conforming to the Swagger spec. Lots of tools support Swagger as a input or output format. Some examples are testing tools, documentation generators and mocking services.
Recently, Swagger has been adopted by the Open API Initiative which has been formed by a lot of big players like Microsoft, Google and IBM. Being the de-facto standard, Swagger is probably the best way to go when it comes to sharing your API definition.
Just like measuring the analytics of your website, it's interesting to see how your API is being used. Monitoring your API will help finding indicators where your API can be improved. It can also help with debugging user problems and reporting and preventing misuse.
Some tools which can help you with setting up a monitoring environment are Runscope and Galileo.
By following the above recommendations, chances are small the user is in need of any support. Still, it's a wise thing to provide a mechanism where users can submit feedback and ask questions. Whether it's open for the community (where you don't have to reply on the feedback yourself), or a closed ticketing system, depends on the use case and the level of service you need to provide.