Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

API Token expiry and error handling


Hello everyone,

Recently we have been encountering some issues with API tokens:

- When we revoke a token manually from the API tokens page, it can take a long time (20min) before the token actually expires. Is this delay normal?

- When we try to fetch projects or project information using an expired token, we get a 200 with an empty array where we used to get a 401 that allowed us to handle the specific case and tell our users they needed to make a new token. Is this intentional? Is there any way for us to check the token validity somehow? (It might be the case that a user simply has no projects. We can't tell the difference between that and an expired token).

Thanks in advance,


5 answers

1 accepted

0 votes
Answer accepted

Hello @Denis Hacquin ,

For the token revocation maintaining a connection for a short period, this token is managed through the Identity system which has various levels of replication tasks required and needs to propagate through the authentication system on an interval to not overload the system with requests, and some of the items are cached in the user session which is the reason for the delay.  The timetable on revoking a API key is mentioned on the "Admin API Key" documentation noting:

Revoking an API key is permanent. It may take up to 10 minutes for a revoked key to stop working.

But, you can manually force the replication tasks by logging off from the user and any changes should take effect and replicate immediately on the users next log in.

As for the 200 HTTP code instead of the 401, it depends on the endpoint that your users are getting the response from. The REST API documentation should specify what they can expect to get back if they provide an expired token.

There is a good example in the following section:

The “Get avatars” method allows anonymous access, so it will return a 200 and no data if you are unauthenticated. It specifies this in the documentation with the phrase “This operation can be accessed anonymously.” and "Permissions required: None."

And the endpoint for "GET /rest/api/3/project" is another with the "This operation can be accessed anonymously." notation, as the value returned is null as they successfully returned everything they have access to view via the permissions of anonymous which is nothing at all.

As for telling the difference between an expired token and a incorrectly formatted request gets a bit tricky other than familiarizing themselves with the expected responses, and noting the difference of in app data results compared to the api response, as authentication related error responses are obligatory by design for security purposes, to prevent exposing any information that could be used to collect additional data about the system. 

When referring to the API tokens you generate at , there is no expiration date on those unless you manually revoke the ones you don't want to use anymore or mark the account that owns the token inactive.  So if your users are constantly revoking tokens, it might be a good idea to enforce a methodology of using a good naming convention on the labels. 

When you're using the Admin API Keys, these items have a 7 day default and 1 year max lifetime, fo familiarizing uses with the expected lifecycle of the token should be adopted into practice.


The problem is, that:

  1. When I use wrong (non-existing) API token (e.g. mistype), API returns standard 401 error.
  2. When I use revoked token, then API switches to anonymous access.
  3. When I use valid token with another email address - e.g. userX token for userY email, then API switches to anonymous access.


The behaviour should be same - API should return 401 for any invalid API token, does not matter is it was revoked or used with wrong email.

Also looking for the same answers.

Thanks a lot for this detailed answer, this is helping a lot !

Hi Denis,

happy to help :)


Suggest an answer

Log in or Sign up to answer