No, and the pressure to make every API a revenue line has done real damage. Some of the most consequential APIs in the history of this space were cost centers by design.
What is not optional is being able to say what it is for. “This API exists to reduce integration cost for our enterprise customers.” “This API exists so partners can embed us and expand our reach.” “This API exists so our own teams stop building the same thing five times.” Each of those is a legitimate business case with a measurable outcome, and each implies a different design, a different support posture, and a different definition of success.
The failure I have watched most often is the API launched on the assumption that it would drive the business, with no specific consumer, no articulated outcome, and no owner — and then quietly judged a disappointment. I have been on the wrong side of that assumption myself.
There is also a genuinely good reason to build one without a revenue plan: an API is research and development for your business model. Exposing a capability and seeing who uses it, how, and for what tells you things about your own business that no strategy deck will. Just be explicit that this is the experiment you are running, and set a decision point.
