This article has extended details covering the Events API End of Life (supported for Box and Workday SAML apps). These changes will impact functionality for end users.

Table of Contents

What is happening and when?
Why is this migration required?
What is the impact to customers?
How long will it take to migrate to the System Log API?
How long will it take to migrate to the System Log API?
What are the different integrations for Events API configuration?
How to successfully migrate a Direct (API) integration?
How to successfully migrate a third-party (ISV) Integration?
 What if the third-party being leveraged is listed, but has no migration guide linked?
​​​​​​​What if the third-party being leveraged is not listed in the table above?

What is happening and when?

To enable customers to leverage a unified platform for enriched, auditable event data, Okta is concentrating its efforts on the new and improved System Log API (/api/v1/logs endpoint) and will end of life the legacy Events API (/api/v1/events endpoint) on January 29, 2021.  After this date, Okta will no longer accept Events API traffic.  All customers who have accessibility to this API as of November 21, 2019 were notified directly of this end of life plan as the access will be disabled on the EOL date.

To continue to operate, all applications and integrations using the Events API must migrate to the System Log API before the EOL date.
 

Why is this migration required?

This change eliminates duplicative systems, enabling the Okta team to focus on the System Log API which manages a wider set of use cases and provides customers with enriched functionality.  The System Log API released in EA early 2018, and GA June 2018.  

The System Log API is also enriched with new features and performance improvements, providing near real-time read-only access to the organization's system log and is the programmatic counterpart of the System Log UI. 
 

What is the impact to customers?

• The Events API will be disabled and will stop collecting event data.

• Okta will no longer accept Events API traffic, support cases, or bug fixes.

• All (direct and third-party) integrations depending on this API will no longer function.

• Customers will no longer be able to access and/or retrieve data.
   

How long will it take to migrate to the System Log API?

Customers should leverage details and documentation below early to plan and execute.  The level of effort and migration path to the System Log API will vary by integration and each integration will need to be migrated.

Okta suggests administrators dedicate ample time to this migration process to ensure all required integrations are properly pulling data from the System Log API before the EOL date.
 

How can a customer verify if they’re leveraging the Events API or the System Log API?

Customers that are using the latest version of the okta-sdk-java  (https://github.com/okta/okta-sdk-java) will only be able to access the /logs API (it no longer supports the /events API). Therefore, any customer using the okta-sdk-java is guaranteed to be using the /logs api. Further, CSMs can use Splunk to determine if any customer is using the /events or /logs API(s). 
 

What are the different integrations for Events API configuration?

Customers can have one, both, or many instances of the following integrations depending on how the Events API is being leveraged.  There are two main ways customers are configured:

• Direct (API) integration:  A customer built a direct (API) integration with the Events API.

• Application/Third-party (ISV - Independent Software Vendor) integration:  There is a third-party integration dependent on the data being provided by the Events API.  
   

How to successfully migrate a Direct (API) integration?

Leverage the following documentation to migrate to the System Log API successfully:

• Events API Migration: This guide aims to help organizations migrate from the Events API to its System Log API replacement. 

• System Log API:  The Okta System Log records system events related to the organization to provide an audit trail that can be used to understand platform activity and to diagnose problems.  

• Additional supporting documentation:

  • Event Catalog 

  • Example of a custom integration migrated to System Log API 
     

How to successfully migrate a third-party (ISV) Integration?

Customers can review the table below to see if an ISV has provided migration documentation to assist customers in migrating to the System Log API.  Okta has listed all known ISV/third-party integrations being leveraged by customers.  

The table below will be kept up to date throughout the EOL notification window (November 21, 2019 - January 29, 2021).  If Okta receives any additional migration guides from third-party vendors during this time period, they’ll be added to this table:  

 What if the third-party being leveraged is listed, but has no migration guide linked?

If a vendor is listed, but there is no migration guide available, the migration details have not been provided at this time.  

If a customer needs a guide from one of these vendors to successfully migrate but it’s not listed above, Okta suggests customers reach out to their ISV connections to encourage them to provide documentation or help migrate the integration to the System Log API.  

If customers have a CSM aligned to their account, CSMs can also assist in this process. 
​​​​​​​

What if the third-party being leveraged is not listed in the table above?

If a customer is using a third-party integration, but it’s not listed above, then Okta isn’t aware of it.  Customers can contact their ISV connections to encourage them to migrate the integration to the System Log API and leverage the Events API Migration document linked above.