Creates a linker value for the specified
linker of authenticated application.

A linker value lets applications supply values to modify its regular expression.

The base regular expression must use a Bitbucket-specific match group (?K)
which will be translated to ([\w\-]+). A value must match this pattern.

Read more about linker values

Creates a new branch restriction rule for a repository.

kind describes what will be restricted. Allowed values include:
push, force, delete, restrict_merges, require_tasks_to_be_completed,
require_approvals_to_merge, require_default_reviewer_approvals_to_merge,
require_no_changes_requested, require_passing_builds_to_merge, require_commits_behind,
reset_pullrequest_approvals_on_change, smart_reset_pullrequest_approvals,
reset_pullrequest_changes_requested_on_change, require_all_dependencies_merged,
enforce_merge_checks, and allow_auto_merge_when_builds_pass.

Different kinds of branch restrictions have different requirements:

• push and restrict_merges require users and groups to be
  specified. Empty lists are allowed, in which case permission is
  denied for everybody.

The restriction applies to all branches that match. There are
two ways to match a branch. It is configured in branch_match_kind:

1. glob: Matches a branch against the pattern. A '*' in
   pattern will expand to match zero or more characters, and every
   other character matches itself. For example, 'foo*' will match
   'foo' and 'foobar', but not 'barfoo'. '*' will match all
   branches.
2. branching_model: Matches a branch against the repository’s
   branching model. The branch_type controls the type of branch
   to match. Allowed values include: production, development,
   bugfix, release, feature and hotfix.

The combination of kind and match must be unique. This means that
two glob restrictions in a repository cannot have the same kind and
pattern. Additionally, two branching_model restrictions in a
repository cannot have the same kind and branch_type.

users and groups are lists of users and groups that are except from
the restriction. They can only be configured in push and
restrict_merges restrictions. The push restriction stops a user
pushing to matching branches unless that user is in users or is a
member of a group in groups. The restrict_merges stops a user
merging pull requests to matching branches unless that user is in
users or is a member of a group in groups. Adding new users or
groups to an existing restriction should be done via PUT.

Note that branch restrictions with overlapping matchers is allowed,
but the resulting behavior may be surprising.

Creates a new build status against the specified commit.

If the specified key already exists, the existing status object will
be overwritten.

Example:

curl https://api.bitbucket.org/2.0/repositories/my-workspace/my-repo/commit/e10dae226959c2194f2b07b077c07762d93821cf/statuses/build/           -X POST -u jdoe -H 'Content-Type: application/json'           -d '{
    "key": "MY-BUILD",
    "state": "SUCCESSFUL",
    "description": "42 tests passed",
    "url": "https://www.example.org/my-build-result"
  }'

When creating a new commit status, you can use a URI template for the URL.
Templates are URLs that contain variable names that Bitbucket will
evaluate at runtime whenever the URL is displayed anywhere similar to
parameter substitution in
Bitbucket Connect.
For example, one could use https://foo.com/builds/{repository.full_name}
which Bitbucket will turn into https://foo.com/builds/foo/bar at render time.
The context variables available are repository and commit.

Approve the specified commit as the authenticated user.

This operation is only available to users that have explicit access to
the repository. In contrast, just the fact that a repository is
publicly accessible to users does not give them the ability to approve
commits.

Creates new comment on the specified commit.

To post a reply to an existing comment, include the parent.id field:

$ curl https://api.bitbucket.org/2.0/repositories/atlassian/prlinks/commit/db9ba1e031d07a02603eae0e559a7adc010257fc/comments/ \
  -X POST -u evzijst \
  -H 'Content-Type: application/json' \
  -d '{"content": {"raw": "One more thing!"},
       "parent": {"id": 5728901}}'

Identical to GET /repositories/{workspace}/{repo_slug}/commits,
except that POST allows clients to place the include and exclude
parameters in the request body to avoid URL length issues.

Note that this resource does NOT support new commit creation.

Identical to GET /repositories/{workspace}/{repo_slug}/commits/{revision},
except that POST allows clients to place the include and exclude
parameters in the request body to avoid URL length issues.

Note that this resource does NOT support new commit creation.

Create a new deploy key in a repository. Note: If authenticating a deploy key
with an OAuth consumer, any changes to the OAuth consumer will subsequently
invalidate the deploy key.

Example:

$ curl -X POST \
-H "Authorization <auth header>" \
-H "Content-type: application/json" \
https://api.bitbucket.org/2.0/repositories/mleu/test/deploy-keys -d \
'{
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDAK/b1cHHDr/TEV1JGQl+WjCwStKG6Bhrv0rFpEsYlyTBm1fzN0VOJJYn4ZOPCPJwqse6fGbXntEs+BbXiptR+++HycVgl65TMR0b5ul5AgwrVdZdT7qjCOCgaSV74/9xlHDK8oqgGnfA7ZoBBU+qpVyaloSjBdJfLtPY/xqj4yHnXKYzrtn/uFc4Kp9Tb7PUg9Io3qohSTGJGVHnsVblq/rToJG7L5xIo0OxK0SJSQ5vuId93ZuFZrCNMXj8JDHZeSEtjJzpRCBEXHxpOPhAcbm4MzULgkFHhAVgp4JbkrT99/wpvZ7r9AdkTg7HGqL3rlaDrEcWfL7Lu6TnhBdq5 mleu@C02W454JHTD8",
    "label": "mydeploykey"
}'

Create an environment.

Update an environment

Create a new deploy key in a project.

Example:

$ curl -X POST \
-H "Authorization <auth header>" \
-H "Content-type: application/json" \
https://api.bitbucket.org/2.0/workspaces/standard/projects/TEST_PROJECT/deploy-keys/ -d \
'{
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDAK/b1cHHDr/TEV1JGQl+WjCwStKG6Bhrv0rFpEsYlyTBm1fzN0VOJJYn4ZOPCPJwqse6fGbXntEs+BbXiptR+++HycVgl65TMR0b5ul5AgwrVdZdT7qjCOCgaSV74/9xlHDK8oqgGnfA7ZoBBU+qpVyaloSjBdJfLtPY/xqj4yHnXKYzrtn/uFc4Kp9Tb7PUg9Io3qohSTGJGVHnsVblq/rToJG7L5xIo0OxK0SJSQ5vuId93ZuFZrCNMXj8JDHZeSEtjJzpRCBEXHxpOPhAcbm4MzULgkFHhAVgp4JbkrT99/wpvZ7r9AdkTg7HGqL3rlaDrEcWfL7Lu6TnhBdq5 mleu@C02W454JHTD8",
    "label": "mydeploykey"
}'

Upload new download artifacts.

To upload files, perform a multipart/form-data POST containing one
or more files fields:

$ echo Hello World > hello.txt
$ curl -s -u evzijst -X POST https://api.bitbucket.org/2.0/repositories/evzijst/git-tests/downloads -F files=@hello.txt

When a file is uploaded with the same name as an existing artifact,
then the existing file will be replaced.

Creates a new issue.

This call requires authentication. Private repositories or private
issue trackers require the caller to authenticate with an account that
has appropriate authorization.

The authenticated user is used for the issue’s reporter field.

A POST request to this endpoint initiates a new background celery task that archives the repo’s issues.

When the job has been accepted, it will return a 202 (Accepted) along with a unique url to this job in the
‘Location’ response header. This url is the endpoint for where the user can obtain their zip files.”

A POST request to this endpoint will import the zip file given by the archive parameter into the repository. All
existing issues will be deleted and replaced by the contents of the imported zip file.

Imports are done through a multipart/form-data POST. There is one valid and required form field, with the name
“archive,” which needs to be a file field:

$ curl -u <username> -X POST -F archive=@/path/to/file.zip https://api.bitbucket.org/2.0/repositories/<owner_username>/<repo_slug>/issues/import

Upload new issue attachments.

To upload files, perform a multipart/form-data POST containing one
or more file fields.

When a file is uploaded with the same name as an existing attachment,
then the existing file will be replaced.

Makes a change to the specified issue.

For example, to change an issue’s state and assignee, create a new
change object that modifies these fields:

curl https://api.bitbucket.org/2.0/site/master/issues/1234/changes \
  -s -u evzijst -X POST -H "Content-Type: application/json" \
  -d '{
    "changes": {
      "assignee_account_id": {
        "new": "557058:c0b72ad0-1cb5-4018-9cdc-0cde8492c443"
      },
      "state": {
        "new": 'resolved"
      }
    }
    "message": {
      "raw": "This is now resolved."
    }
  }'

The above example also includes a custom comment to go alongside the
change. This comment will also be visible on the issue page in the UI.

The fields of the changes object are strings, not objects. This
allows for immutable change log records, even after user accounts,
milestones, or other objects recorded in a change entry, get renamed or
deleted.

The assignee_account_id field stores the account id. When POSTing a
new change and changing the assignee, the client should therefore use
the user’s account_id in the changes.assignee_account_id.new field.

This call requires authentication. Private repositories or private
issue trackers require the caller to authenticate with an account that
has appropriate authorization.

Creates a new issue comment.

$ curl https://api.bitbucket.org/2.0/repositories/atlassian/prlinks/issues/42/comments/ \
  -X POST -u evzijst \
  -H 'Content-Type: application/json' \
  -d '{"content": {"raw": "Lorem ipsum."}}'

Create a deployment environment level variable.

Endpoint to create and initiate a pipeline.
There are a couple of different options to initiate a pipeline, where the payload of the request will determine which type of pipeline will be instantiated.

Trigger a Pipeline for a branch

One way to trigger pipelines is by specifying the branch for which you want to trigger a pipeline.
The specified branch will be used to determine which pipeline definition from the bitbucket-pipelines.yml file will be applied to initiate the pipeline. The pipeline will then do a clone of the repository and checkout the latest revision of the specified branch.

Example

$ curl -X POST -is -u username:password \
  -H 'Content-Type: application/json' \
 https://api.bitbucket.org/2.0/repositories/jeroendr/meat-demo2/pipelines/ \
  -d '
  {
    "target": {
      "ref_type": "branch",
      "type": "pipeline_ref_target",
      "ref_name": "master"
    }
  }'

Trigger a Pipeline for a commit on a branch or tag

You can initiate a pipeline for a specific commit and in the context of a specified reference (e.g. a branch, tag or bookmark).
The specified reference will be used to determine which pipeline definition from the bitbucket-pipelines.yml file will be applied to initiate the pipeline. The pipeline will clone the repository and then do a checkout the specified reference.

The following reference types are supported:

• branch
• named_branch
• bookmark
• tag

Example

$ curl -X POST -is -u username:password \
  -H 'Content-Type: application/json' \
  https://api.bitbucket.org/2.0/repositories/jeroendr/meat-demo2/pipelines/ \
  -d '
  {
    "target": {
      "commit": {
        "type": "commit",
        "hash": "ce5b7431602f7cbba007062eeb55225c6e18e956"
      },
      "ref_type": "branch",
      "type": "pipeline_ref_target",
      "ref_name": "master"
    }
  }'

Trigger a specific pipeline definition for a commit

You can trigger a specific pipeline that is defined in your bitbucket-pipelines.yml file for a specific commit.
In addition to the commit revision, you specify the type and pattern of the selector that identifies the pipeline definition. The resulting pipeline will then clone the repository and checkout the specified revision.

Example

$ curl -X POST -is -u username:password \
  -H 'Content-Type: application/json' \
 https://api.bitbucket.org/2.0/repositories/jeroendr/meat-demo2/pipelines/ \
 -d '
  {
     "target": {
      "commit": {
         "hash":"a3c4e02c9a3755eccdc3764e6ea13facdf30f923",
         "type":"commit"
       },
        "selector": {
           "type":"custom",
              "pattern":"Deploy to production"
          },
        "type":"pipeline_commit_target"
   }
  }'

Trigger a specific pipeline definition for a commit on a branch or tag

You can trigger a specific pipeline that is defined in your bitbucket-pipelines.yml file for a specific commit in the context of a specified reference.
In addition to the commit revision, you specify the type and pattern of the selector that identifies the pipeline definition, as well as the reference information. The resulting pipeline will then clone the repository a checkout the specified reference.

Example

$ curl -X POST -is -u username:password \
  -H 'Content-Type: application/json' \
 https://api.bitbucket.org/2.0/repositories/jeroendr/meat-demo2/pipelines/ \
 -d '
  {
     "target": {
      "commit": {
         "hash":"a3c4e02c9a3755eccdc3764e6ea13facdf30f923",
         "type":"commit"
       },
       "selector": {
          "type": "custom",
          "pattern": "Deploy to production"
       },
       "type": "pipeline_ref_target",
       "ref_name": "master",
       "ref_type": "branch"
     }
  }'

Trigger a custom pipeline with variables

In addition to triggering a custom pipeline that is defined in your bitbucket-pipelines.yml file as shown in the examples above, you can specify variables that will be available for your build. In the request, provide a list of variables, specifying the following for each variable: key, value, and whether it should be secured or not (this field is optional and defaults to not secured).

Example

$ curl -X POST -is -u username:password \
  -H 'Content-Type: application/json' \
 https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pipelines/ \
 -d '
  {
    "target": {
      "type": "pipeline_ref_target",
      "ref_type": "branch",
      "ref_name": "master",
      "selector": {
        "type": "custom",
        "pattern": "Deploy to production"
      }
    },
    "variables": [
      {
        "key": "var1key",
        "value": "var1value",
        "secured": true
      },
      {
        "key": "var2key",
        "value": "var2value"
      }
    ]
  }'

Trigger a pull request pipeline

You can also initiate a pipeline for a specific pull request.

Example

$ curl -X POST -is -u username:password \
  -H 'Content-Type: application/json' \
 https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pipelines/ \
 -d '
  {
    "target": {
      "type": "pipeline_pullrequest_target",
      "source": "pull-request-branch",
      "destination": "master",
      "destination_commit": {
        "hash": "9f848b7"
      },
      "commit": {
        "hash": "1a372fc"
      },
      "pullrequest": {
        "id": "3"
      },
      "selector": {
        "type": "pull-requests",
        "pattern": "**"
      }
    }
  }'

Signal the stop of a pipeline and all of its steps that not have completed yet.

Create a schedule for the given repository.

Create a repository level known host.

Create a repository level variable.

Create a workspace level variable.

Creates a new project.

Note that the avatar has to be embedded as either a data-url
or a URL to an external image as shown in the examples below:

$ body=$(cat << EOF
{
    "name": "Mars Project",
    "key": "MARS",
    "description": "Software for colonizing mars.",
    "links": {
        "avatar": {
            "href": "data:image/gif;base64,R0lGODlhEAAQAMQAAORHHOVSKudfOulrSOp3WOyDZu6QdvCchPGolfO0o/..."
        }
    },
    "is_private": false
}
EOF
)
$ curl -H "Content-Type: application/json" \
       -X POST \
       -d "$body" \
       https://api.bitbucket.org/2.0/workspaces/teams-in-space/projects/ | jq .
{
  // Serialized project document
}

or even:

$ body=$(cat << EOF
{
    "name": "Mars Project",
    "key": "MARS",
    "description": "Software for colonizing mars.",
    "links": {
        "avatar": {
            "href": "http://i.imgur.com/72tRx4w.gif"
        }
    },
    "is_private": false
}
EOF
)
$ curl -H "Content-Type: application/json" \
       -X POST \
       -d "$body" \
       https://api.bitbucket.org/2.0/workspaces/teams-in-space/projects/ | jq .
{
  // Serialized project document
}

Creates a new pull request where the destination repository is
this repository and the author is the authenticated user.

The minimum required fields to create a pull request are title and
source, specified by a branch name.

curl https://api.bitbucket.org/2.0/repositories/my-workspace/my-repository/pullrequests \
    -u my-username:my-password \
    --request POST \
    --header 'Content-Type: application/json' \
    --data '{
        "title": "My Title",
        "source": {
            "branch": {
                "name": "staging"
            }
        }
    }'

If the pull request’s destination is not specified, it will default
to the repository.mainbranch. To open a pull request to a
different branch, say from a feature branch to a staging branch,
specify a destination (same format as the source):

{
    "title": "My Title",
    "source": {
        "branch": {
            "name": "my-feature-branch"
        }
    },
    "destination": {
        "branch": {
            "name": "staging"
        }
    }
}

Reviewers can be specified by adding an array of user objects as the
reviewers property.

{
    "title": "My Title",
    "source": {
        "branch": {
            "name": "my-feature-branch"
        }
    },
    "reviewers": [
        {
            "uuid": "{504c3b62-8120-4f0c-a7bc-87800b9d6f70}"
        }
    ]
}

Other fields:

• description - a string
• close_source_branch - boolean that specifies if the source branch should be closed upon merging