Key concepts of API Connect analytics

An overview of how API Connect analytics works.

How the gateway and analytics services work together

When a user calls one of your published APIs, the gateway that processes the API call creates an API event record that contains details of the API call such as the application ID, current time, result code, etc. For a full list of all the data stored in an API event record, see API event record field reference. The gateway buffers API event records for each API call until a threshold of either number of events, or elapsed time is reached. When this threshold is reached, the API events are sent in bulk to the analytics subsystem. API events are sent by the gateway to the management subsystem with TCP, and if a network failure occurs the gateway does retry. However, the gateway does not retain unsent API event records and retry indefinitely, and so delivery of every API event record is not guaranteed.

Customizing the analytics data that is stored for your APIs

Note: What API consumer analytics are displayed in the Developer Portal depends on the visibility configuration settings. For more information, see Configuring analytics in the developer portal.
When you configure an API in the API Manager UI, you choose what data is stored in the API event records for calls to that API with the activity log property. The activity log property has separate settings for successful API calls, and for failed API calls. The activity log options are:
  • none - API events are not logged.
  • activity - Logs the API resource URI. activity is the default log setting for successful API calls.
  • header - Logs the API resource URI and HTTP headers.
  • payload - Logs API resource URI, HTTP headers, and request and response payloads. payload is the default log setting for failed API calls, since the response payload might have useful information on the cause of the failure.

If you want to make specific customizations to your API event data you can use a gateway script or the set-variable operation in the definitions of each API that you want to customize. See Customizing data with a gateway script or set-variable operation.

Accessing your analytics data

You can view your analytics data in the API Manager and Developer Portal UIs.
  • In the API Manager UI, the provider organization owner can see analytics data for APIs that are published in their catalogs.
  • In the Developer Portal UI, the API consumer can see analytics data for APIs published in their consumer organization.
The maximum number of API events that can be accessed from the UIs is 10,000. The maximum number of event records that can be displayed per page in the UIs is 200.

Your analytics data can also be accessed by using the toolkit CLI or REST API.

You can manage user access to analytics data with User roles and permissions. For more information about user-based analytics data visibility, see Catalogs, spaces, and analytics

You can export analytics data from your UIs, however, UI export is not a practical method if you want to export more than 200 API event records. Use the toolkit CLI or REST API to export more than 200 API event records at a time. If you think that you might want to regularly export all your analytics data, then consider Offloading your analytics data to a third-party system.

Offloading your analytics data to a third-party system

The API event data that is received from your gateways can be directed to a third-party system, instead of or in addition to being stored by the analytics subsystem.

You can offload your analytics data to an AWS S3 or Splunk server. For more information about offloading, see Offloading analytics data.