If you take one thing from everything I have written, take this: storytelling is the most important tool in the API toolbox. Not because marketing beats engineering, but because an API is an abstraction and abstractions do not explain themselves.
The practical form of it is a drumbeat rather than a campaign. A blog that publishes something real every week or two — a new capability, a customer using it well, a problem you solved, a design decision and its reasoning, a change and why it happened. The blog for your API is the most important signal you can send, because its cadence tells everyone whether the platform is alive. Silence is also a story, and it is not the one you want told.
Tell stories about your own process, too. Publicly explaining how you design, govern and change your APIs is a genuine sign of maturity and it does two jobs at once: it teaches your consumers what to expect, and it recruits the people who want to work somewhere that thinks this carefully.
And keep it concrete. The story that works is almost never “our API is powerful and flexible.” It is “here is a specific person with a specific problem, here is what they built, here is what changed for them.” That is the version people repeat.
