Understanding events and its lifecycle with API Portal

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.

Event Types

Different event types captured with in webMethods API Portal:

Event Type Description
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

Event states

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.

Querying events:

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.

Parameter Description default
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)  

Event structure

Responses to above API would contain a collection of events in below format

      "creationdate":"2019-04-21 10:57:09"

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)


You might find useful: