Setting up and troubleshooting Adobe IO Events can be intricate due to the multifaceted technology stack, which requires AEM and Adobe IO to work in tandem.

I’ve compiled a list of Common Problems and Solutions that I encountered while configuring this setup.

For detailed instructions on setting up Adobe IO Events, please refer: Enable Adobe IO Events in AEMaaCS


After the setup is done, Health checks fail with the following error:

"error": "BadRequest:[400 Bad Request] during [PUT] to [] [ProviderApi#update(String,String,String,String,ProviderInputModel)]: [{\"reason\":\"Bad Request. Request id: QIj3SJOhn9WxsJDzAFBGXKkEhOyzSiAy.\",\"message\":\"The current event provider's is associated with another workspace (check the provider's rel:update links to its workspace).. Please take a note of the http response `x-request-id` header for debugging/support.\"}]",


Based on the error it appears that your AEM provider is already registered with a different workspace, and now you are attempting to register it with a new workspace. To resolve this issue, you will need to delete the existing provider association from the old workspace before registering it with the new one.

Here’s how you can do it:

Make a note of the provider ID mentioned in the error message above: 5fc8cab5-d2f1-43db-ad53-24d270afeaac.

1) To determine which workspace this provider is associated with, you’ll need to utilize the Provider API. This requires two pieces of information:

  • a. Generate the access token using the private key of your current workspace.
  • b. Obtain the client ID from the workspace.json file associated with your current workspace.

2) Search for your provider ID in the JSON response from provider api, and you’ll be able to locate the workspace it’s currently associated with.

In the provider JSON, we notice that it’s linked to a different workspace, such as workspace ID ending with “712”, rather than the one mentioned in the error logs ending with “436”. This indicates that the provider is already associated with a different workspace.

3) Delete the provider using the Provider API.

You can directly use the link from rel:update in the above JSON.

x-api-key represents the client ID, and the authorization should be set as bearer with the access token.

4) Once deleted, rerun the find providers api. Now, you will not find the provider ID in the JSON.
5) Redeploy your project code with the workspace impl OSGI config.
6) On your local environment, you might need to restart AEM.
7) Refresh the health checks, and now they should work.
8) You should be able to see the AEM provider in the provider list on the Adobe IO workspace.


If you encounter an error preventing you from deleting a project due to associations with providers, it indicates that your project is linked with providers, and these associations must be deleted before you can delete the workspace.


Follow the same steps as outlined above to resolve this issue.


BadRequest:[400 Bad Request] during [POST] to [] [ImsApi#getJwtAccessToken(String,String,String)]: [{\"error_description\":\"Could not match JWT signature to any of the bindings\",\"error\":\"invalid_token\"}]


Your com.adobe.aio.aem.workspace.internal.WorkspaceSupplierImpl.cfg.json configuration doesn’t seem to have the correct jwt token. Ensure that you have generated the correct token using the private key (generated via openssl) from the Developer Console. Then, use its encoded pkcs8 (aio.encoded.pkcs8) in the AEM WorkspaceSupplierImpl OSGI configuration.

base64 -i private.pkcs8.key