Bitbucket Cloud workspaces API for Atlassian Connect app

Hello,

We are exploring workspaces API for Bitbucket Cloud and just wondering if this possible that following endpoint could return more than one workspace for Atlassian Connect app.

https://developer.atlassian.com/bitbucket/api/2/reference/resource/workspaces

Atlassian Connect app for bitbucket cloud is installed on behalf of a specific workspace - so always one workspace can be accessed per JWT? Am I right?

Regards,
Piotr Bojko

Hi @piotr.bojko,
there are a couple of things here. First of all there are different types of Connect apps. I would recommend that you create an app by going to the Workspace admin > Develop apps. This way you will get app secret that can be used for all authenticated calls to all the workspaces in which your app will be installed into.

The API you are referencing is a special one, and can not be used by connect apps to return the workspaces they have access to. If you require to keep track of which workspaces your app is installed into, you can use the lifecycle hooks. These hooks are sent to your app to notify you whenever someone installs the app into a workspace. App descriptor

I hope this helps?

1 Like

Hi,

We already have a working Atlassian Connect app (Atlas Google Chat bot for Bitbucket | Atlassian Marketplace).

First of all - we need to discover a particular SLUG of a worskpace for which our app needs to do its job. This slug is needed in Bitbucket APIs like accessing to a repositories of a workspace.

We don’t want to keep track of which workspaces our app is installed into but rather to fetch a slug of a particular workspace for an particular installation.

We are using ACE and lifecycle hooks are handled by the ACE itself. However ACE does not store nor expose the workspace but rather the user (team) for which the installation is done. Se example of data below:

[
  {
    "_id": {"$oid": "some id"},
    "clientKey": "ari:cloud:bitbucket::app/{some hash like bambo jambo}",
    "key": "clientInfo",
    "val": {
      "productType": "bitbucket",
      "principal": {
        "username": "codedoers",
        "display_name": "codedoers",
        "uuid": "{some id}",
        "links": {
          "self": {
            "href": "https://api.bitbucket.org/2.0/teams/%some id"
          },
          "html": {
            "href": "https://bitbucket.org/%some id/"
          },
          "avatar": {
            "href": "https://bitbucket.org/account/codedoers/avatar/"
          }
        },
        "created_on": "2014-04-08T16:33:41.881302+00:00",
        "type": "team",
        "properties": {
        },
        "has_2fa_enabled": null
      },
      "eventType": "installed",
      "baseUrl": "https://bitbucket.org",
      "actor": {
        "type": "user",
        "uuid": "some id
        "account_id": "some id"
      },
      "publicKey": "some key,
      "user": {
        "username": "codedoers",
        "display_name": "codedoers",
        "uuid": "{some de}",
        "links": {
          some links here
        },
        "created_on": "2014-04-08T16:33:41.881302+00:00",
        "type": "team",
        "properties": {
        },
        "has_2fa_enabled": null
      },
      "key": "dev-com.codedoers.atlas-bot-piotr.bojko-issue-02",
      "baseApiUrl": "https://api.bitbucket.org",
      "clientKey": "same key as above",
      "sharedSecret": "some secret"
    }
  }
]

Mentioned data does not expose any workspace id or slug. In 90% of cases val.principal.username does map to workspace slug in some way, however this is only guessing and still 10% of cases are not mapped correctly.

For now we are using API endpoint mentioned earlier to fetch a workspace list for a particular clientKey using ACE api client and getting one workspace with the slug we need. However this an additional call and this endpoint is described to return a list of workspaces which in context of Atlassian Connect app should return only one workspace per clientKey.

Am I missing something? I don’t see any changes in ACE to implement notion of a workspace itself to expose it.

Regards,
Piotr

Looking through the install lifecycle hook body, it doesn’t look like there’s any reference to the workspace it was installed on? It passes the principal who installed it – is there anyway to programatically map that to the workspace?

1 Like

@NikhilUnni We are using following resource to check workspace under which are app is being installed.

https://developer.atlassian.com/bitbucket/api/2/reference/resource/workspaces