Confirm Proper Procedure to Regenerate the SCIM API Key

[Jesse Ortega Jr]

Hello. Looking to find the correct process of renewing our SCIM API key.

Claude's instructions indicate that the SCIM API key should be renewed; however, we would like to confirm the proper procedure directly with Atlassian.

From Claude:
After you regenerate the SCIM API key in Atlassian, the critical step is updating that new key over on the Okta side — regenerating a new API key disables the existing one, so you need to know where the old key is being used so you can update it after generating the new one. Concretely, for Okta: Okta

1. Copy the new key immediately — Atlassian won't show you the API key and SCIM base URL again after you set up provisioning, so grab both values right after regenerating. Atlassian Support
2. Update the Okta Atlassian Cloud app's provisioning config — the provisioning configuration for the Atlassian Cloud OIN app needs to be updated from the Okta Admin dashboard with the new key. Okta
3. Specifically in Okta: go to the Atlassian Cloud application → Provisioning tab → Configure API Integration, and paste in the new API key (and SCIM base URL, if it changed) there.
4. Test the connection in Okta (there's usually a "Test API Credentials" button) to confirm provisioning is working again before relying on it.
5. Keep in mind the expiration change Atlassian rolled out: when you regenerate an API key for SCIM, we automatically set it to expire in one year, so it's worth noting the new expiration date somewhere (calendar reminder, ticket, etc.) so you're not caught off guard next time

[James Gamble]

Hola Jesse,

The procedure you quoted is broadly correct, with one important operational point: regenerating the SCIM API key immediately invalidates the existing key, so provisioning between Okta and Atlassian will fail until the new credentials are saved in Okta.

An Atlassian organization admin should first open Okta and identify the Atlassian Cloud application currently handling provisioning. Keep that configuration open to make the replacement window as short as possible.

In Atlassian Administration, go to admin.atlassian.com > select the organization > Security > Identity providers > select the identity provider directory > More actions > Regenerate API key. Copy the new API key immediately. Atlassian won’t display the key again after you leave the credentials screen, and the regenerated key will expire one year after creation.

Then go to Okta Admin Console > Applications > Applications > Atlassian Cloud > Provisioning > Configure API Integration. Replace the API key, confirm the SCIM base URL, select Test API Credentials, and save once the test succeeds. Atlassian’s current Okta provisioning guide confirms this path and the credential test.

The SCIM base URL normally belongs to the existing directory and shouldn’t need to change when only the key is regenerated. To be sure, I’d compare it with the value shown by Atlassian rather than assuming.

After saving, verify a low-risk provisioning action, such as updating a test user or test group, and review the Okta System Log for any provisioning failures. It’s also worth recording the new expiration date and setting an internal reminder well before it expires.

One final clarification: this is managed at the Atlassian organization and Guard level rather than within Jira Service Management, and the person regenerating the key must be an organization admin. A Jira product admin role by itself isn’t sufficient.

Thanks,

James