The reason you're getting the concepts jumbled up is that the vendors are selling them in a package. But they are definitely separate concepts.
An API Gateway provides a central access point for managing, monitoring, and securing access to your publicly exposed web services. It would also allow you to consolidate services across disparate endpoints as if they were all coming from a single host. For example let's say you had ten different service endpoints that were all part of a single "suite" of services. Rather than informing consumers of your service to use service1.yourcompany.com for one service and service2.yourcompany.com for another and so forth, you can instead have them all point to api.yourcompany.com/service1 or api.yourcompany.com/service2 and the gateway would be responsible for redirecting the requests to the appropriate endpoints.
An ESB is an internal "Bus" that allows applications and services to communicate with each other in an uncoupled fashion. All applications can hook into the bus and they can receive any message that interests them when published by another application. They can also publish their own messages that another application may listen for and respond to. The applications are not responsible for connecting with each other directly, they publish their messages to the bus and all interested parties listen and react.
Logically the API Gateway is not a replacement for an ESB but rather an enhancement for a service oriented architecture.
