Let me bring up a diagram first.
In a real world distributed deployment, only the WSO2 APIM Gateway would be exposed to the outside world. So with the creation of keys for a certain application that would be subscribed to many API's, (If you are not familiar with this context, please refer to the blog post I had written before The Basic Architecture of WSO2 APIM - Part 2- The Store - under the hood for a crash course) you would be able to invoke an API via the gateway.
Ideally an Application would have the consumer_key and the consumer_secret hardcoded in the application it self. When invoking the API, the username, password would have to be added and the application would pass in the username, password, consumer_key and consumer_secret to the gateway. The Gateway has some token API's . which are
When calls are made to these API's, the gateway calls the Key manager Jax-RX in order to verify the access the token. The key-manager would call the AM_DB, retrieve the access token, and verify the access token. it will return the API Info DTO which includes the meta data of the access token, which includes the validity period, refresh token and scopes.
When the API's are invoked, the Gateway does not call the Key manager at every invocation. The APIM Gatway makes use of a cache for this. However, this cache can be turned off. 
Invoking the API
When the API's are invoked there are several authorization grant types that we could use. The WSO2 APIM supports the same grant types the WSO2 IS supports. The password grant type is used only when the application is a trusted application Client Credentials grant type requires only the consumer_key & consumer_secret. .
When the API's is created it will store the synapse configuration of the API in the WSO2 APIM Gateway, being another ESB (WSO2 ESB). When the api is invoked and it hits the Gateway, it will execute the API's in and out sequences which would have a set of handlers. The API when created would have a set of default handlers defined in the API .
1) Security handler/
The security handler is to validate the Oauth token used to invoke the API.
2) Throttle handler/
Throttles the request based on the throttle policy. This is done based on two counts,
the global count and the local count.
3) Stats hander/
Helps to push data to the BAM for analytics.
4) Google analytics handler/
Pushes events to Google analytics for analytics.
5) Extentions handler/
Executes extention's sequences
Each of these handler classes has 2 methods
1) handle request
2) handle response
These methods have been overridden in each of these handlers to accomplish the task that the handler is written for. There is also a possibility that you could write your own handler, and plug it in. Details on this could be found at .
I hope you were able to gain a basic knowledge on what happens internally when an API is invoked on the WSO2 APIM, on a highlevel. By going through the references you would be able to gain a much detailed knowledge on the APIM gateway and WSO2 APIM as a whole.