Kin mentions that:
One thing to know about these API management service providers is, well...they are API management service providers. To my knowledge they don’t actually deploy your API for you, they help you build a strategy, and manage the API. But you still need to rely on other tools and in-house resources to deliver your API.This is where I'd disagree slightly. In the case of an API Gateway, it can also be used as a service delivery platform to deliver an API in front of existing enterprise system systems. This is because API Gateways include many adapters to, for example, various message queues, TIBCO EMS/Rendezvous, databases, and FTP/SFTP. These are used to deliver a REST API interface in front of an enterprise system which does not natively support REST, not to mention JSON, OAuth, or OpenID. This can be as simple as delivering a REST API interface in front of an existing SOAP service within the enterprise, to mapping from REST into messages placed on the message queue, through to mapping from "lightweight" identity mechanisms suitable for APIs (such as OpenID or OAuth) through to enterprise identity management (e.g. mapping from Google OpenID to Oracle OAM). So, an API Gateway usually does not only manage the API, it actually delivers the API too.