Users cannot be found through AP.request(‘/rest/api/search’) and AP.request(‘/rest/api/search/user’) anymore

For some time, we have get some requests from our clients, that our application has stopped working, and more specifically: the user search functionality (this is one of the core functionality our application).

After a deeper analysis, I noticed that the functionality, that has been working for almost 2 years suddenly always returns 0 results.
This is the REST, which we are used:


also we are tried this query:


but the result is still the same.

I would like to hear some answers to the questions:

  1. What is the reason this sudden changes
  2. How in the current situation, can I replace this user search functionality to another one?
  3. Is there any working workaround?

I can add, that application working with none authentication (this is very simple app):
“authentication”: {
“type”: “none”

This is probably caused by API changes done due to GDPR regulations. Search “GDPR” statement through this community.

In short - your app should not handle users (like search them) by its name, login, email or so but rather the anonymous ID or mechanisms like OAUTH.

I am not a pro in this topic though, only guessing.


Hi @AdrianKruk are you using impersonation? What is the add-on key?

Hi @AdrianKruk, I hope you are doing great!

Feel free to get in touch with our Support team, if you would like to provide further details from your investigation. That way we can try to reproduce that on our side, and check if that’s a known bug, or something expected due to recent changes.

Thank you!

Hi everyone,
Since my colleague @AdrianKruk is currently on vacation, I will try to continue this thread.

We are aware of changes in Confluence Cloud API that have entered into force and described here. But, as it was described, the CQL input query still allows us to search users by Full name (taking into account user’s profile visibility) - we want to use this method.

On the our addon side, we use AP to make a request to REST API. After careful inspect network activity, we noticed that search requests are sent with the api-client-key: {{our_addon_key}} HTTP header. The result of such request is always an empty user list. When we make the request manually using curl without this header, the response contains the correct values.

We are still trying to fix the user search ability in our product.

Our addon-key:

Best regards, Kamil

Thank you for the information @KamilStepien. It seems to be an issue with only this addon. I tested the same request for other addon keys in the api-client-key header and I can see results are returned. I am able to reproduce 0 results for this addon in my test tenant. We will investigate further to see what the issue is.

@KamilStepien I am seeing that there is no user found for which is the reason for 0 search results. Did anything change in your addon recently? @JatinChopra @akashyap Can we please check why this addon does not have a user associated with it after installation?

@SwatiKatta No, we didn’t change anything recently. As you can see on Marketplace - our last release was March 23, 2020 and the user search ability has worked properly so far. It stopped working without any changes to addon.

Hi @KamilStepien, we took a look at your connect descriptor and saw the authentication type is set to “none” and hence doesn’t end up provisioning a user account id.

Can you please update this piece:

"authentication": {
        "type": "jwt"

Hi @JatinChopra, as my colleague wrote at the first post - our addon is very simple app that is provided as static addon. We don’t have a server side code and use only JavaScript API (AP) to make a request to Confluence REST API - so we don’t need to use the JWT authentication method.

Hi, but we seem to have listed “none” as the auth type. Can we try anything besides that and jwt ?

@SwatiKatta @JatinChopra I changed the authorization method to JWT on my local development environment. The user associated with our addon has been created and the search users functionality has started working properly, but it’s not the solution for us. We don’t have a server side code, so we are not able to handle the “installed” and “uninstalled” lifecycle callbacks - but this is required when using the JWT authentication method (during tests, I just mock these callbacks on my local environment).

I encountered the same issue and have been forced to update the backend of my app.
This doesn’t have to be expensive / costly - you just need to be able to respond with a 200 OK response to the lifecycle POST. But its a major pain.

we just discovered about this while investigating on another issue.

We noticed the discrepancy of results between:
AP.request('/rest/api/search/user?cql=user.accountid in (abc, def)')
today because the users: abc and def actually exists in Confluence and /rest/api/user?accountId=abc' returns the result as expected while /rest/api/search/user?cql=user.accountid in (abc) did not (statusCode:200 but with 0 results).

Similarly with @KamilStepien, we only want to use AP as we are making the request from frontend JS. And we found that AP.request('/wiki/rest/api/user/bulk?accountId=abc&accountId=def') could get the job done -

@SwatiKatta @JatinChopra hope this info helps with uncovering anything odd or new.


Found out why AP.request('/rest/api/search/user') was returning 0 results for me and I’ve shared the findings in linked post. :pray:t4: