Start and Cancel Builds
In this article, we explore common use cases concerning starting and canceling builds via REST API. These are helpful when you need to:
Start a TeamCity build from an external software.
Implement a complex build logic by invoking REST API from a Command Line build runner.
See also general info about triggering requests.
Start regular build
To be able to start a build, you need to access a build queue via this endpoint:
Queueing a new build requires two steps:
Prepare the request payload (that is, the
Buildentity) which will represent the target build.
POSTrequest with the payload.
The payload of this
Build entity must include a reference to a build configuration (or, in REST API terms,
BuildType). We will include it as a sub-entity of
To add a build to the queue, send a
POST request with the body specified in Step 1:
The request headers should include an authorization header (unless the guest authorization scheme is used) and, optionally,
The endpoint will respond with a short description of the launched build. It will also include the
TCSESSIONID cookie: you can reuse it to skip authorization in the following runs.
Start custom build
A more complex example is when you need to run a build with settings that differ from those specified in its build configuration. In this case, you need to send extra data about the build in your request.
From the fields available for the
Build entity, we will pass the following:
personal: to define that the build is personal
branchName: to launch a build in a non-default branch
agent: to select a specific agent for this build by sending an
comment: to supply a build with a description
properties: to set custom properties by sending a complex
Most of the data should be available locally. However, in this example we request a specific agent which requires knowing its ID. If you know an agent by name, you can find its ID by sending the following request:
The eventual payload for our
POST request will look as follows:
Send it via a
POST request as in the basic case. As a result, a personal build will be run in the
myBranch branch on the specified agent and with the redefined
Advanced build run
In this example, we will show how to compose a payload to rerun a build, clean its sources, and select a specific revision.
Build entity we will supply:
triggeringOptions: to specify extra parameters by sending the
triggeringOptions, we want to enable clean checkout, rebuild all dependencies before the current build, and put the build at the top of the queue.
lastChanges, we'll use the locator as follows:
version: SHA of the specific revision already detected by TeamCity
BuildTypeLocatorwhich will point to the same
BuiltTypeas the one we run the build on.
The expected payload:
Get queued build
After queueing a build, you can check its status:
BuildQueueLocator represents a queued build – you can supply the build ID you received on sending the
This request returns a
Build entity. By default, TeamCity will return basic fields of the entity. For polling purposes, you might want to receive only the build status. You can limit the scope of fields available in the response by using the `?fields" parameter in the request path (read more):
As a result of the call, TeamCity will return the
Build entity with only two fields populated:
Cancel queued build
To cancel a just queued build, send:
BuildCancelRequest entity is used as a payload.
This entity comprises two fields:
comment: to provide an optional comment on why the build was canceled
readdIntoQueue: a boolean property which declares if this is a request to restore a previously canceled build; as we are aiming to cancel the build, not to restore it, we will set it to
The resulting payload:
To cancel a build by its ID, send:
Alternatively, you may choose to simply delete a queued build (if you don't need its metadata). To do so, run a
DELETE request on the same endpoint: