This is a series of stories I’m doing as part of my API Transit work, trying to map out a simple journey that some of my clients can take to rethink some of the basics of their API strategy. I’m using a subway map visual, and experience to help map out the journey, which I’m calling API transit–leveraging the verb form of transit, to describe what every API should go through.
Beyond communication, make sure there is adequate support across API teams, and the services, tooling, and processes involved with operations. If an API goes unsupported, it might as well not exist at all, making standardized, comprehensive support practices essential. Every API should have an owner, with a contact information published as part of all API definitions. Ideally, every API owner has a backup point of contact to go to if someone should leave a company, or is out sick.
Similar to the communications stop along this journey, there a handful of common support building blocks you see present within the leading API pioneers portals. These are the four I recommend baking in by default to all of your API portals, and anywhere API discovery and documentation exists.
- Email - Make sure there is support available via email channels, with a responsive individual on the other end–with accountability.
- Tickets - Consider a ticketing system for submitting and supporting requests around API operations.
- Dedicated - Identify one, or many individuals who can act as internal, partner, and public support when it makes sense.
- Office Hours - Consider one time a week where there is a human being available in person, or online to answer direct question.
Every single API should have a support element present as part of its operations. Each API definition allows for the inclusion of responsible point of contact via email, and other channels–make use of it. Support should be baked into each API’s definition, making it accessible across the API lifecycle, in a machine readable way. Ideally, every API developer provides support for their own work, bringing them closer to how their solutions are working, or not working for consumers.
API support isn’t rocket surgery, but will make or break your API operations if not done well. The APIs that perform the best, will have strong support behind them. The APIs that go dormant, or aren’t reliable will not have proper support. Developers do not think about support by default, which means it will often go overlooked unless a more senior developer, business user, or manager steps up. This is why API operations is a team sport, because there are different skill levels, and personalities at play, and while proper support won’t be everyone’s strength, it is something everyone should be responsible for.
