Assigning Client ID Dynamically in API Connect
IBM API Connect works based on the Client ID for its enforcement rules. Only when the caller being identified with its client ID, the subscription of the product, the rate limiting, the reporting of the API usage will then starts to work. The API consumer must present their client ID, obtained from the API subscription, either in the request header or the query parameters to identify themself to start to call the APIs.
However there always be some special case you may need to tweak the process a bit to fit into some requirement which is not normal.
I have the following requirement, consumer would just call the API with HTTP basic authentication, they will not change the existing code to include client id information, but still want to have those features that are designed for client ID only including rate limiting, reporting.
Let’s achieve this with the preflow policies.
Preflow Policies
By default, whenever an API is called, a series of policies, called the preflow policies, are invoked prior to the policy assembly configured in the API definition. However, by using a global policy you can, if required, fully customize the behavior of these policies, controlling if and when they are invoked, and with what customization.