webMethods API Portal guide
Often customers would like to build/integrate various events/actions that are performed within API Portal with external systems. When one of those events triggered within the system, the events are persisted in API Portal event store and for some events they are delivered to the configured webHook synchronously.
Different event types captured with in webMethods API Portal:
|REQUEST_ACCESS_TOKEN||Raised when there is a new application creation request for an API|
|RENEW_ACCESS_TOKEN||Raised when there is a renewal request for an Application|
|REVOKE_ACCESS_TOKEN||Raised when there is a revoke of application subscription from an API|
|UPDATE_USER||Raised when a user update his user profile information|
|DELETE_USER||Raised when a user delete his account in API Portal|
|REQUEST_SUBSCRIPTION||Raised when there is a new subscription request for a package|
|RENEW_SUBSCRIPTION||Raised when there is a new renewal of subscription request for a package|
|REVOKE_SUBSCRIPTION||Raised when there is a unsubscription request for a package|
|APPLICATION_UPDATE||Raised when there is a update of specific attributes of an application|
|USER_SIGNUP||Raised when there is a new user signup against API Portal|
Various events captured with in the API Portal has states associated with them. Below diagram depicts various event states and its state transition with in system.
For example when there is a new REQUEST_ACCESS_TOKEN event is forked in the system, initially the event will be in NEW state. The moment event is pushed/delivered to its provider(API Gateway) the state changes from NEW to INPROGRESS. When gateway eventually gets back to API Portal with a application, the respective event status changes from INPROGRESS to COMPLETED.
Events do have expiration(configurable). By default it is 30days. After 30days of time period events transition to EXPIRED state. Meaning API Portal can wait max upto 30days from API Gateway to deliver the application back to API Portal.
API Portal exposed a standard REST interface for querying the various events in the API Portal.
|curl --request GET \
--url 'https://api.portal/abs/apirepository/v1/events' \
--header 'authorization: Basic c3lzdGVtOm1hbmFnZXI='
Filtering query results:
Above REST interface consumes below optional query parameters to fine tune your search results.
|eventType||Comma seperated values of different event types listed above||If not specified all events will be pulled|
|eventStatus||Comma seperated values of different event status(NEW/INPROGRESS/COMPLETED/REJECTED)||NEW|
|apiId||GUID of specific API(incase of API specific events)|
|duration||duration filter(for ex 1d - will query only the events that are forked in last 24hours)|
Responses to above API would contain a collection of events in below format
Skeleton of the event payload would look like
- executor - basic info on the user who is performing the request.
- source - the object on which the event is performed (API GUID in our case)
- contextdata - the dynamic context information with respect to the event(mainly the user entered data - the app name/description/redirect uri)