Not Even Wrong
Sometimes I run across articles that make me want to reach through the screen, find the author, and say "Stop it. You missed the point entirely and you're just making things worse." The article The essential difference between microservices and APIs is one of those cases.
To use an analogy, consider an article titled The essential difference between Ethernet and communication theory. And then you read the article and it talks about how Ethernet is better than the old networks because you can get better overall throughput if you have relatively sparse transmitters. It doesn't name the older network technology, just talks about how much better Ethernet is. Yes, Ethernet can do better than a TokenRing network, but that's not what you said you're going to be talking about.
Basically, the title compares an implementation of one concept to a different (but related) concept itself, then goes on to compare two implementations. Which does a disservice to both implementations and the concept.
Microservices and monoliths are architectural design patterns, and the both have their pros and cons. For example, microservices let you deploy small pieces and scale them up/out individually, but are hard to test end 2 end. Monoliths are easy to test and debug end 2 end, but hard to scale up/out. There are lots of other differences and other options besides those two, but that's a whole different topic. And choosing the correct implementation is important if you expect your system to be flexible enough to last. (If you want to dive deeper let me know and maybe we can do a Kata event with your team)
APIs, on the other hand are all about high level architecture and design decisions. Your API (and the way this article is written we're talking about the public API) defines what you can do from outside the system and how you interact with it. It defines the interface but explicitly does not define the implementation. You could have a single monolith, you could have an API gateway over microservices, or something completely different behind the gateway. The whole point of an API is that the consumer of the API doesn't need to know (or care) what the implementation is. And defining the correct API for a project is critical to making it easy for others to use, easy to expand, and easy to adapt to future requirements.
So, the next time you need to compare two things, make sure you know what you're comparing and make sure the things you're comparing are, in fact, comparable. Otherwise you might find yourself in this situation. Or, as Wolfgang Pauli is supposed to have said,
