An API strategy answers four questions in plain language: which business capabilities are we exposing, who is meant to consume them, what outcome do we expect from that consumption, and what are we committing to in return — support, stability, availability, and for how long.
Notice that none of those are technical. The most common failure I see is an API strategy that is actually an architecture document: gateways, protocols, and standards, with no statement of what business the APIs are in. That produces well-engineered APIs that nobody uses, which is the most expensive outcome available.
A small team absolutely needs this, and it fits on one page. Skipping it is how you end up with an API that was built because someone assumed it would drive the business, launched with no consumer in mind, and quietly went nowhere. I have watched that story play out for fifteen years, including in my own projects.
Write down the capabilities. Write down who they are for. Write down what you will and will not promise. Revisit it when the answers change. That is a strategy; everything else is implementation.
