If the API you subscribe to is secured via an API Key, you will have to pass on this API Key to the API Gateway in a HTTP Header. Using curl, this will look as follows:
$ curl -H 'X-ApiKey: (your API Key)' https://chinteg-wicked-api.contenthub.haufe.io/desired_api/some_endpoint
If you pass on a correct API Key, the API Gateway will let you call the backend API, using the plan you selected when subscribing to the API, for your application.
Note: Please be aware that the API key is bound to the application it was generated for. You should have different API keys for different applications. Do not re-use the API Keys, even if it is possible (the API Gateway cannot notice).
If the API you have subscribed to is secured via the OAuth 2.0 Client Credentials Flow, you will first need to acquire an Access Token for the API before you can call any of the API end points.
Leveraging curl, the call has to look as follows:
$ curl -X POST --header 'Content-Type: application/x-www-form-urlencoded' -d 'grant_type=client_credentials&client_id=(your client id)&client_secret=(your client secret)' 'https://chinteg-wicked-api.contenthub.haufe.io/auth/(auth method)/api/(desired api)/token'
Please note that the same kind of request has to be used regardless of the API in the backend. The /oauth2/token end point is not actually provided by the backend API, but by the API Gateway. This means the authorization calls will always look the same, no matter which API (here e.g. /desired_api/) is to be used.
If the POST request was successful, you will receive an access token which is valid for a certain period of time:
{"token_type":"bearer","access_token": "db530d89558843a99ec80f639434faa8","expires_in": 3600}
In green above, the access token is highlighted. This can in turn be used for real calls to the API in the background, using the same example URL as above, this would be:
$ curl --header 'Authorization: Bearer db530d89558843a99ec80f639434faa8' https://chinteg-wicked-api.contenthub.haufe.io/desired_api/some_endpoint
Chances are good that this kind of authorization is automatically supported in case you are using common frameworks when implementing your application, such as Java Spring. For you, calling an API would be transparent, as long as you provide your framework with Client ID and Client Secret. This is though very implementation specific and is not covered further here.
See also:
Depending on the API and the type of authentication (auth method), wicked supports all the above OAuth2 flows.