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!


Working with UUIDs and their curly brackets, workspace names or repository slugs in Bitbucket


We are currently running an EAP for Forge for Bitbucket, if you want to join the community group send us a request to join  here:

I will approve your request right away (Unless I'm sleeping and you'll need to wait a few hours).

If you just want to read more about the EAP, head here: Announcing the start of the Bitbucket Cloud x Forge EAP 


You just retrieved the response from a Bitbucket REST API and need to use the returned UUID for a subsequent request, but the documentation says that you need their name or slug (e.g. workspace name and repo_slug).


So what do you do?

Just use the UUIDs directly as-is. Keep the curly brackets as well.


For example, if you are looking for more details about a repository via the GET Get a repository REST API endpoint simply replace {workspaceUUID} and {repositoryUUID} in the URL and use{workspaceUUID}/{repositoryUUID} instead of{workspace}/{repo_slug} .


How does that work when responding to a Forge trigger?

The same is true also when processing Forge triggers. The workspaceUUID and the repositoryUUID are available in the event details while the slugs are not provided.

As an example, here is what is logged as a response to a avi:bitbucket:created:pullrequest trigger:

# trigger definition in the manifest.yml
- key: pullrequest-created-event
function: main
- avi:bitbucket:created:pullrequest

# function in the index.js
export async function prtrigger(event, context) {
console.log(`event: ${JSON.stringify(event)}`); 


The logged information:



The UUIDs can then be used directly in a subsequent request:

const res = await api


The curly brackets have to stay

In the example above, both the event.workspace.uuid and the event.repository.uuid values are surrounded by the curly brackets.

When they are removed (e.g. with the slice method event.repository.uuid.slice(1, -1);), the requestBitbucket fails with a URL not allowed error:

URL not allowed: /2.0/repositories/bd5ab8df-e1b9-4a2c-8d9d-156e32704c99/e4403a47-6010-4a36-b477-117db9680f45


Using curl directly

A Forge app is the most powerful, while still easy, way to automate any operation in Bitbucket or to extend it. We recommend using it for any custom requirement.

However, if you are using a curl directly and receiving an error stating that The requested repository either does not exist or you do not have access and using the UUIDs in the request, you might need to encode the curly brackets so replacing { with %7B and } with %7D.


Want to check a real-life example? New to Forge?

If you would like to try this logic out in a fully working app, I’ve created this one for assigning reviewers automatically when creating a PR. The list of reviewers is in defined in each repository via a configuration file that the apps read.

And if you want to know more, Check out the documentation and the getting started example.



Log in or Sign up to comment
AUG Leaders

Atlassian Community Events