httpAuthOn this page:

...

General Usage Principles

...

You can start by opening http://teamcity:8111/app/rest URL in your browser: this page will give you several pointers to explorer explore the API.

Use http://teamcity:8111/app/rest/application.wadl to  to get the full list of supported requests and names of parameters. This is the primary source of discovery for the supported requests and their parameters. The same data is also exposed in Swagger format via .../app/rest/swagger.json endpoint 

 Swagger issue: https://youtrack.jetbrains.com/issue/TW-44962

For the list of supported locator dimensions, use "$help" locator.

Experiment and read the error messages returned: for the most part they should guide you to the right requests.

...

• Using basic HTTP authentication (it can be slow with certain authentications, see below). Provide a valid TeamCity username and password with the request. You can force basic auth by including "httpAuth" before the "/app/rest" part: e.g. http://teamcity:8111/httpAuth/app/rest/builds
• Using access to the server as a guest user (if enabled) include "guestAuth" before the "/app/rest" part: e.g.: http://teamcity:8111/guestAuth/app/rest/builds
• if you are checking REST GET requests from within a browser and you are logged in to TeamCity in the browser, you can just use "/app/rest" URL: e.g. http://teamcity:8111/app/rest/builds

There is also a workaround for not sending credentials with every requestAuthentication can be slow when not built-in authentication module is used, consider applying the session reuse approach for reusing authentication between sequential requests.

If you perform a request from within a TeamCity build, consider using for a limited set of build-related operations (like downloading artifacts) you can use values of teamcity.auth.userId/teamcity.auth.password system properties as credentials (within TeamCity settings you can reference them as %system.teamcity.auth.userId% and %system.teamcity.auth.password%). The server URl is available as %teamcity.serverUrl% within a build.

Within a build, a request for current build details can look like:
curl -u "%system.teamcity.auth.userId%:%system.teamcity.auth.password%" "%teamcity.serverUrl%/httpAuth/app/rest/builds/id:%teamcity.build.id%"

Superuser access

You can use the super user account with REST API: just provide no user name and the generated password logged into the server log.

...

Under the http://teamcity:8111/app/rest/ or http://teamcity:8111/app/rest/latest URL the latest version is available.
Under the http://teamcity:8111/app/rest/<version> URL, the current version is available and earlier versions CAN be available. Our general policy is to supply TeamCity with at least one previous version.
In e.g. in TeamCity 10.x for <version> you can use "10.0" for the current and "9.1", "9.0", "8.1", "6.0" to get earlier versions of the protocol. Protocol version corresponds to the TeamCity version where it was first introduced.

...

The general structure of the URL in the TeamCity API is teamcityserver:port/<authType>/app/rest/<apiVersion>/<restApiPath>?<parameters>, where

• teamcityserver and port define the server name and the port used by TeamCity. This page uses "http://teamcity:8111/" as example URL
• <authType> (optional) is the authentication type to be used, this is generic TeamCity functionality
• app/rest  is the root path of TeamCity REST API
• <apiVersion> (optional) is a reference to specific version of REST API
• <restApiPath>?<parameters> is the REST API part of the URL

When <restApiPath> represents a collection of items .../app/rest/<itmes> <items> (e.g. .../app/rest/builds), then the URL regularly accepts the "locator" parameter which can filter the items returned. Individual items can regularly be addressed by a URL in the form form of .../app/rest/<itmes>/<item_locators>. Both multiple and single items requests regularly support the fields parameter.

Locator

In a number of places, you can specify a filter string which defines what entities to filter/affect in the request. This string representation is referred to as "locator" in the scope of REST API.

...

Note: If the value contains the "," symbol, it should be enclosed into parentheses: "(<value>)". The value of a dimension can also be encoded as Base64url and sent as "<dimension>:($base64:<base64-encoded-value >)" instead of " <dimension>: <value>".

Examples:

http://teamcity:8111/app/rest/projects gets you the list of projects
http://teamcity:8111/app/rest/projects/<projectsLocator> -  http://teamcity:8111/app/rest/projects/id:RESTAPIPlugin  (the example id is used) gets you the full data for the REST API Plugin project.
http://teamcity:8111/app/rest/buildTypes/id:bt284/builds?locator=<buildLocator> - http://teamcity:8111/app/rest/buildTypes/id:bt284/builds?locator=status:SUCCESS,tag:EAP - (example ids are used) to get builds
http://teamcity:8111/app/rest/builds/?locator=<buildLocator> - to get builds by build locator.

Supported HTTP Methods

• GET: retrieves the requested data. e.g. usually .../app/rest/entities retrieves a list of entities, .../app/rest/entities/<entity locator> retrieves a single entity
• POST: creates the entity in the request adding it to the existing collection. When posting XML, be sure to specify the "Content-Type: application/xml" HTTP header. e.g. to create a new entity, one regularly needs to post  a single entity data to the .../app/rest/entities URL
• PUT: based on the existence of the entity, creates or updates the entity in the request. e.g. supported for some entities, for URLS like .../app/rest/entities/<entity locator>
• DELETE: removes the requested data e.g. for the .../app/rest/entities/<entity locator> URL

Response Formats

The TeamCity REST APIs returns HTTP responses in the following formats according to the HTTP "Accept" header:

Full and Partial Responses

...

It is possible to change the set of fields returned for XML and JSON responses for the majority of requests.
This is done by supplying the fields request parameter describing the fields of the top-level entity and sub-entities to return in the response. An example syntax of the parameter is: field,field2(field2_subfield1,field2_subfield1). This basically means "include field and field2 of the top-level entity and for field2 include field2_subfield1 and field2_subfield1 fields". The order of the fields specification plays no role.

(not public as this is still experimental, needs unification of these locators)
When collection of items is included, some entities support providing additional locator to affect the items in those collections. That is performed by adding "$locator(<locator>)" into the fields under the collection field.

...

If you get an error in response to your request and want to investigate the reason, look into rest-related server logs.

To get details about each processed request, turn on debug logging (e.g. set Logging Preset to "debug-rest" on the Administration/Diagnostics page or modify the Log4J "jetbrains.buildServer.server.rest" category) .

...

TeamCity REST can be configured to allow cross-origin requests using the rest.
If you want to cors.origins internal property.

To allow requests from a page loaded from a specific domain

...

:

• • Add the page address (including the protocol and port

...

• • , do not use wildcards)  to the comma-separated internal property rest.cors.origins

...

• • , e.g. 

    rest.cors.origins=http://myinternalwebpage.org.com:8080,https://myinternalwebpage.org.com

To enable support for a preflight OPTIONS request

...

:

1. Add the rest.cors.optionsRequest.allowUnauthorized=true

...

1.  internal property

...

1. .
2. Restart the

...

1. TeamCity server.
2. Use the '/app/rest/latest

...

1. ' URL for the requests

...

1.  Do not

...

1. use '/app/rest

...

1. ', do not use the 'httpAuth' prefix.

If that does not help, enable debug logging and look for related messages. If there are none, capture the browser traffic and messages to investigate the case.

API Client Recommendations

...

• Make root REST API URL configurable (e.g. allow to specify an alternative for "app/rest/<version>" part of the URL). This will allow to direct the client to another version of the API if necessary.
• Ignore (do not error out) item's attributes and sub-items which are unknown to the client. New sub-items are sometimes added to the API without version change and this will ensure the client is not affected by the change.
• Set large (and make them configurable) request timeouts. Some API calls can take minutes, especially on a large server.
• Use HTTP sessions to make consecutive requests (use TCSESSIONID cookie returned from the first authenticated response instead of supplying raw credentials all the time). This saves time on authentication which can be significant for external authentication providers.
• Beware of partial answers when requesting list of items: some requests are paged by default. Value of the "count" attribute in the response indicate the number of the items on the current page and there can be more pages available. If you need to process more (e.g. all) items, read and process "nextHref" attribute of the response entity for items collections. If the attribute is present it means there might be more items when queried by the URL provided. Related locator dimensions are "count" (page limit) and "lookupLimit" (depth of search). Even when the returned "count" is 0, it does not mean there are no more items if there is "nextHref" attribute present.
• Do not increase the  "lookupLimit" value in the locators without a second thought. Doing so has the direct effect of loading the server more and may require increased amounts of CPU and memory. It is assumed that those increasing the default limit understand the negative consequences for the server performance.
• Do not abuse the ability to execute automated requests for TeamCity API: do not query the API too frequently and restrict the data requested to only that necessary (using due locators and specifying necessary fields). Check the server behavior under load from your requests. Make sure not to repeat the request frequently if it takes time to process the request.

TeamCity

...

Since TeamCity 10:
Licensing information: GET http://teamcity:8111/app/rest/server/licensingData

...

Data Entities Requests

Projects and Build Configuration/Templates Lists

List of projects: GET http://teamcity:8111/app/rest/projects
Project details: GET  GET http://teamcity:8111/app/rest/projects/<projectLocator>
where <projectLocator> can be id:<internal_project_id> or name:<project%20name>

List of Build Configurations: GET http://teamcity:8111/app/rest/buildTypes
List of Build Configurations of a project: GET GET http://teamcity:8111/app/rest/projects/<projectLocator>/buildTypes<projectLocator>buildTypes 

Get projects with sub-projects/ Build Configurations data and their order as configured by the specified user on the Overview page: GET  GET  http://teamcity:8111/app/rest/projects?locator=selectedByUser:current&fields=count,project(id,parentProjectId,projects(count,project(id),$locator(selectedByUser:current)),buildTypes(count,buildType(id),$locator(selectedByUser:current)))

List of templates for a particular project: GET http://teamcity:8111/app/rest/projects/<projectLocator>/templates.templates
List of all the templates on the server: GET http://teamcity:8111/app/rest/buildTypes?locator=templateFlag:true

Project Settings

Get project details: GET GET http://teamcity:8111/app/rest/projects/<projectLocator>/
Delete a project: DELETE http://teamcity:8111/app/rest/projects/<projectLocator>/
Create a new empty project: POST plain text (name) to http://teamcity:8111/app/rest/projects/
Create (or copy) a project: POST XML <newProjectDescription name='New Project Name' id='newProjectId' copyAllAssociatedSettings='true'><parentProject locator='id:project1'/><sourceProject locator='id:project2'/></newProjectDescription> to http://teamcity:8111/app/rest/projects. Also see an example.   Note that editing via the TeamCity Web UI will ve disabled for projects created via the REST API. 
Edit project parameters: GET/DELETE/PUT http://teamcity:8111/app/rest/projects/<projectLocator>/parameters/<parameter_name> name> (produces XML, JSON and plain text depending on the "Accept" header, accepts plain text and XML and JSON) Also supported are requests .../parameters/<parameter_name>/name and .../parameters/<parameter_name>/value.

Project name/description/archived status: GET/PUT http://teamcity:8111/app/rest/projects/<projectLocator>/<field_name> (accepts/produces text/plain) where <field_name> is one of "name", "description", "archived".

Project's parent project: GET/PUT XML http://teamcity:8111/app/rest/projects/<projectLocator>/parentProject

Project Features

Project features (e.g. issue trackers, versioned settings, custom charts, shared resources and third-party report tabs) are exposed as entries under the "project" node and via dedicated requests.

List of project features:  http://teamcity:8111/app/rest/projects/<projectLocator>/projectFeatures
List features with filtering: http://teamcity:8111/app/rest/projects/<projectLocator>/projectFeatures To filter features, add "?locator=<projectFeaturesLocator>" to the URL e.g. to find all issue tracker features of GitHub type, use the locator "type:IssueTracker,property(name:type,value:GithubIssues)"

Create feature: POST to  http://teamcity:8111/app/rest/projects/<projectLocator>/projectFeatures

Edit features: GET/DELETE/PUT http://teamcity:8111/app/rest/projects/<projectLocator>/projectFeatures/<featureId>

VCS Roots

List all VCS roots: GET http://teamcity:8111/app/rest/vcs-roots, add locator=<vcsRootLocator> parameter to list only the VCS roots matched
Get details of a VCS root/delete a VCS root: GET/DELETE http://teamcity:8111/app/rest/vcs-roots/<vcsRootLocator> , where "<vcsRootLocator>" can be "id:<internal VCS root id>" or other VCS root locator
Create a new VCS root: POST VCS root XML (similar to the one like retrieved for by a GET request for VCS root details) to http://teamcity:8111/app/rest/vcs-roots

Also supported:

GET/PUT http://teamcity:8111/app/rest/vcs-roots/<vcsRootLocator>/properties/<property_name> 
GET/PUT PUT http://teamcity:8111/app/rest/vcs-roots/<vcsRootLocator>/<field_name>name>, where <field_name> is one of the following: name, shared, project "id", "name", "project" (post project locator to "project" to associate a VCS root with a specific project).

A " 'VCS root" ' is the setting configured in the TeamCity UI, a "VCS root instance" is the an internal TeamCity entity which is derived from the "VCS root" to perform the actual VCS operation.
If the a VCS root has no %-references to parameters, a single VCS root corresponds to a single "VCS root instance".
If a VCS root has %-reference to a parameter and the reference resolves to a different value when the VCS root is attached to different configurations or when custom builds are run, a single "VCS root" can generate several "VCS root instances".

There are two endpoints dedicated at using dedicated to being used in commit hooks from the version control repositories:
POST http://teamcity:8111/app/rest/vcs-root-instances/checkingForChangesQueue?locator=<vcsRootInstancesLocator> <vcsRootInstancesLocator> - schedules checking for changes for the matched VCS root instances and returns the list of VCS root instances matched (just like GET like GET http://teamcity:8111/app/rest/vcs-root-instances?locator=<vcsRootInstancesLocator><vcsRootInstancesLocator>)
POST http://teamcity:8111/app/rest/vcs-root-instances/commitHookNotification?locator=<vcsRootInstancesLocator> <vcsRootInstancesLocator> - schedules checking for changes for the matched VCS root instances and returns plain-text human-readable message on the action performed, HTTP response 202 in case of successful operation
Both perform the same action (put the VCS root instances matched by the <locator>) to the queue for "checking for changes" process and differ only in responses they produce.
Note that since the matched VCS root instances are the same as for .../app/rest/vcs-root-instances?locator=<locator> request and that means that by default only the first 100 are matched and the rest are ignored. If this limit is hit reached, consider tweaking the <locator> to match less fewer instances (recommended) or increase the limit, e.g. by adding ",count:1000" to the locator.

VCS root instance locator

Some of the supported "<vcsRootInstancesLocator>" from above:
type:<VCS root type> - VCS root instances of the specified version control (e.g. "jetbrains.git", "mercurial", "svn")
vcsRoot:( <vcsRootLocator>) - VCS root instances corresponding to the VCS root matched by "<vcsRootLocator>"
buildType:(<buildTypeLocator>) - VCS root instances attached to the matching build configuration
property:(name:<name>,value:<value>,matchType:<matching>) - VCS root instances with the property of name "<name><name>" and value matching condition "<matchType>" (e.g. equals, contains) by the value "<value>".

Build Configuration And Template Settings

Build Configuration/Template details: GET  http://teamcity:8111/app/rest/buildTypes/<buildConfigurationLocator> (details on the Build Configuration locator).

Please note that there is no transaction, etc. support for settings editing in TeamCity, so all the settings modified via REST API are taken into account at once. This can result in half-configured builds triggered, etc. Please make sure you pause a build configuration before changing its settings if this aspect is important for your case.

To get aggregated status for several build configurations, see Build Status Icon section.

Build configuration settings: GET/DELETE/PUT http://teamcity:8111/app/rest/buildTypes/<buildTypeLocator>/settings/<setting_name> 
Build configuration parameters: GET/DELETE/PUT
PUT http://teamcity:8111/app/rest/buildTypes/<buildTypeLocator>/parameters/<parameter_name>
   (produces XML, JSON and plain text depending on the "Accept" header, accepts plain text and XML and JSON). The requests .../parameters/<parameter_name>/name and .../parameters/<parameter_name>/value are also supported.

Build configuration steps: GET/DELETE DELETE http://teamcity:8111/app/rest/buildTypes/<buildTypeLocator>/steps/<step_id>

Create build configuration step: POST POST http://teamcity:8111/app/rest/buildTypes/<buildTypeLocator>/steps. The XML/JSON posted is the same as retrieved by GET request to .../steps/<step_id> except for the secure settings like password: these are not included into responses and should be supplied before POSTing back


...

Since TeamCity 10, it is possible to disable/enable artifact dependencies and agent requirements:
Disable/enable an artifact dependency PUT PUT http://teamcity:8111/app/rest/buildTypes/<buildTypeLocator>/artifact-dependencies/<id>/disabled (put " true " or "false" text as text/plain)
Disable/enable an agent requirement PUT PUT http://teamcity:8111/app/rest/buildTypes/<buildTypeLocator>/agent-requirements/<id>/disabled (put " true " or "false" text as text/plain)

Build configuration VCS roots: GET/DELETE  http://teamcity:8111/app/rest/buildTypes/<buildTypeLocator>/vcs-root-entries/<id>
Attach VCS root to a build configuration: POST http://teamcity:8111/app/rest/buildTypes/<buildTypeLocator>/vcs-root-entries. The XML/JSON posted is the same as retrieved by GET request to http://teamcity:8111/app/rest/buildTypes/<buildTypeLocator>/vcs-root-entries/<id> except for the secure settings like password: these are not included into responses and should be supplied before POSTing back.

Create a new build configuration with all settings: POST http://teamcity:8111/app/rest/buildTypes. The XML/JSON posted is the same as retrieved by GET request. (Note that /app/rest/project/XXX/buildTypes still uses the previous version notation and accepts another entity.)  Note that editing via the TeamCity Web UI will ve disabled for build configurations created via the REST API.

Create a new empty build configuration: POST plain text (name) to http://teamcity:8111/app/rest/projects/<projectLocator>/buildTypes

Copy a build configuration: POST XML <newBuildTypeDescription name='Conf Name' sourceBuildTypeLocator='id:bt42XXX' copyAllAssociatedSettings='true' shareVCSRoots='false'/> to http://teamcity:8111/app/rest/projects/<projectLocator>/buildTypes

Since TeamCity 2017.2: Read, detach and attach a build configuration from/to a template: GET/DELETE/POST/PUT http://teamcity:8111/app/rest/buildTypes/<buildTypeLocator>/templates 
Before 2017.2: Read, detach and attach a build configuration from/to a template: GET/DELETE/PUT http://teamcity:8111/app/rest/buildTypes/<buildTypeLocator>/template  (PUT accepts template locator with the "text/plain" Content-Type)

...

The most frequently used values for "<buildTypeLocator>" are id:<buildConfigurationOrTemplate_id> and name:<Build%20Configuration%20name>.

Since TeamCity 2017.2, the experimental type locator is supported with one of the values: regular, composite or deployment

Other supported dimensions are (these are in experimental state):
internalId - internal id of the build configuration
project - <projectLocator> to limit the build configurations to those belonging to a single project
affectedProject - <projectLocator> to limit the build configurations under a single project (recursively)
template - <buildTypeLocator> of a template to list only build configurations using the template
templateFlag - boolean value to get only templates or only non-templates
paused - boolean value to filter paused/not paused build configurations

{hidden-data}
compatibleAgent
compatibleAgentsCount
parameter
filterByBuilds
{hidden-data}

Build Requests

List builds: GET http://teamcity:8111/app/rest/builds/?locator=<buildLocator>

Get the list of build configurations in a project with the status of the last finished build in each build configuration: 
GET http://teamcity:8111/app/rest/buildTypes?locator=affectedProject:(id:ProjectId)&fields=buildType(id,name,builds($locator(running:false,canceled:false,count:1),build(number,status,statusText)))

Build Locator

Using a locator in build-related requests, you can filter the builds to be returned in the build-related requests. It is referred to as "build locator" in the scope of REST API.

There is "default" filter For some requests, a default filtering is applied which returns only "normal" builds . To return all builds, use "defaultFilter:false" dimension.
The default filter is that only (finished builds which are not canceled, not failed-to-start, not personal, and on default branch (in branched build configurations) are included. If only not finished builds are requested (), unless those types of builds are specifically requested via the locator. To turn off this default filter and process all builds, add "defaultFilter:false" dimension to the build locator. Default filtering varies depending on the specified locator dimensions. e.g. via "running:true"), "when "agent" or "user" dimensions are present - default filtering is not applied, personal, canceled and failed to start builds are included into the results.

Examples of supported build locators:

...

The list of supported build locator dimensions:

project:<project locator> locator> - limit the list to the builds of the specified project (belonging to any build type directly under the project). 
affectedProject:<project locator> locator> - limit the list to the builds of the specified project (belonging to any build type directly or indirectly under the project)
buildType:(<buildTypeLocator>),defaultFilter:false - only all the builds of the specified build configuration

status:<SUCCESS/FAILURE/ERROR> - list builds with the specified status only
user:(<userLocator>) - limit builds to only those triggered by the user specified
personal:<true/false/any> - limit builds by the personal flag. By default, perfsonal personal builds are not included.

canceled:<true/false/any> - limit builds by the canceled flag. By default, canceled builds are not included.
failedToStart:<true/false/any> - limit builds by the failed to start flag. By default, canceled builds are not included.

state: <queued/running/finished> - - limit builds by the specified state.
running:<true/false/any> - limit builds by the running flag. By default, running builds are not included.
state:running,hanging:true - fetch hanging builds (since TeamCity 10.0) 

pinned:<true/false/any> - limit builds by the pinned flag.

revision:<REVISION> - find builds by revision, e.g. all builds of the given build configuration with the revision: /app/rest/builds?locator=revision:(REVISION),buildType:(id:BUILD_TYPE_ID). See more information below.
agentName:<name> - agent name to return only builds ran on the agent with name specified

sinceBuild:(<buildLocator>) - limit the list of builds only to those after the one specified
sinceDate:<date> <date> - limit the list of builds only to those started after the date specified. The date should be in the same format as dates returned by REST API (e.g. "20130305T170030+0400").

count:<number> <number> - serve only the specified number of builds
start:<number> <number> - list the builds from the list starting from the position specified (zero-based)
lookupLimit:<number> <number> - limit processing to the latest N builds only (the default is 5000). If none of the latest N builds match the other specified criteria of the build locator, 404 response is returned . for single build request and empty collection for multiple builds request. See related note in the section abov

Queued Builds

GET http://teamcity:8111/app/rest/buildQueue

Supported locators:

• project:<locator>
• buildType:<locator>

Get details of a queued build:
GET http://teamcity:8111/app/rest/buildQueue/id:XXX

For queued builds with snapshot dependencies, the revisions are available in the revisions element of the queued build node if a revision is fixed (for regular builds without snapshot dependencies it is not).

Get compatible agents for queued builds (useful for builds having "No agents" to run on)
GET http://teamcity:8111/app/rest/buildQueue/id:XXX/compatibleAgents

Examples:
List queued builds per project:
GET  GET http://teamcity:8111/app/rest/buildQueue?locator=project:<locator>

List queued builds per build configuration:
GET   GET  http://teamcity:8111/app/rest/buildQueue?locator=buildType:<locator>

...

Triggering a Build

To start a build, send a POST request to http://teamcity:8111/app/rest/buildQueue with the "build" node (see below) in content - the same node as details of a queued build or finished build. The queued build details will be returned.

...

<build>
  <triggeringOptions cleanSources="true" rebuildAllDependencies="true" queueAtTop="true"/>
  <buildType id="buildConfID"/>
  <lastChanges>
    <change id="modificationId" personal="false"/>
  </lastChanges>
</build>

curl -v -u user:password http://teamcity.server.url:8111/app/rest/buildQueue --request POST --header "Content-Type:application/xml" --data-binary @build.xml

Build Tags

Get tags: GET http://teamcity:8111/app/rest/builds/<buildLocator>/tags/
Replace tags: PUT http://teamcity:8111/app/rest/builds/<buildLocator>/tags/  (put the same XML or JSON as returned by GET)
Add tags: POST http://teamcity:8111/app/rest/builds/<buildLocator>/tags/  (post the same XML or JSON as returned by GET or just a plain-text tag name)
(<buildLocator> here should match a single build only)

...

Get current pin status: GET http://teamcity:8111/app/rest/builds/<buildLocator>/pin/ (returns "true" or "false" text)
Pin: PUT http://teamcity:8111/app/rest/builds/<buildLocator>/pin/ (the text in the request data is added as a comment for the action)
Unpin: DELETE http://teamcity:8111/app/rest/builds/<buildLocator>/pin/ (the text in the request data is added as a comment for the action)
(<buildLocator> here should match a single build only)

...

...

...

See the canceledInfo element of the build item (available via GET GET http://teamcity:8111/app/rest/builds/<buildLocator > <buildLocator>)

Build Artifacts

<path> below GET http://teamcity:8111/app/rest/builds/<build_locator>/artifacts/content/<path> (returns the content of a build artifact file for a build determined by <buid_locator>)

<path> above can be empty for the root of build's artifacts or be a path within the build's artifacts. The path can span into the archive content, e.g. dir/path/archive.zip!/path_within_archive

GET http://teamcity:8111/app/rest/builds/ <build_locator> /artifacts/content/ <path> (returns the content of a build artifact)

Media-Type: application/octet-stream or a more specific media type (determined from artifact file extension)
Possible error: 400 if the specified path references a directory

GET http://teamcity:8111/app/rest/builds/<build_locator>/artifacts/metadata/<path> (returns information about a build artifact)
Media-Type: application/xml or application/json

GET GET http://teamcity:8111/app/rest/builds/<build_locator>/artifacts/children/<path> (returns the list of artifact children for directories and archives)
Media-Type: application/xml or application/json
Possible error: 400 if the artifact is neither a directory nor an archive

GET http://teamcity:8111/app/rest/builds/<build_locator>/artifacts/archived/<path>?locator=pattern:<wildcard> (returns the archive containing the list of artifacts under the path specified. The optional locator parameter can have file <wildcard> to limit the files only to those matching the wildcard)
Media-Type: application/zip
Possible error: 400 if the artifact is neither a directory nor an archive

{hidden-data}
Since *TeamCity 9.1*:
"locator" parameter is supported for the artifacts listing requests, e.g. "{{recursive:true,browseArchives:true}}". "recursive:true" dimension allows to list files recursively, "browseArchives:true" treat supported archives as "directories", listing their content
{hidden-data}

Examples:

GET http://teamcity:8111/app/rest/builds/id:100/artifacts/children/my-great-tool-0.1.jar\!/META-INF 
GET http://teamcity:8111/app/rest/builds/buildType:(id:100Build_Intallers),status:SUCCESS/artifacts/metadata/my-great-tool-0.1.jar\!/META-INF/MANIFEST.MF
GET http://teamcity:8111/app/rest/builds/buildType:(id:100Build_Intallers),number:16.7.0.2/artifacts/metadata/my-great-tool-0.1.jar!/lib/commons-logging-1.1.1.jar!/META-INF/MANIFEST.MF
GET http://teamcity:8111/app/rest/builds/buildType:(id:100Build_Intallers),tag:release/artifacts/content/my-great-tool-0.1.jar!/lib/commons-logging-1.1.1.jar!/META-INF/MANIFEST.MF

Authentication

If you download the artifacts from within a TeamCity build, consider using teamcity.auth.userId/teamcity.auth.password system properties as credentials for the download artifacts request: this way TeamCity will have a way to record that one build used artifacts of another and will display it on the build's Dependencies tab.

...

Get the list of all of the changes included into the build: GET http://teamcity:8111/app/rest/changes?locator=build:(id:<buildId>)
Get details of an individual change:  GET http://teamcity:8111/app/rest/changes/id:changeId
Get information about a changed file action: the files node lists changed files. The information about the changed file action is reported via the  changeType  attribute for the files listed as one of the following:  added, edited, removed, copied or unchanged.

Filter all changes by a locator: GET http://teamcity:8111/app/rest/changes?locator=<changeLocator><changeLocator>
Note that the change id is the change's internal id, not the revision. The id can be seen in the change node listed by the REST API or in the URL of the change details (as modId).

Get all changes for a project: GET http://teamcity:8111/app/rest/changes?locator=project:projectId
Get all the changes in a build configuration since a particular change identified by its id:  http://teamcity:8111/app/rest/changes?locator=buildType:(id:buildConfigurationId),sinceChange:(id:changeId)
Get pending changes for a build configuration http://teamcity:8111/app/rest/changes?locator=buildType:(id:BUILD_CONF_ID),pending:true

<agent id="1" name="agentName" typeId="1" connected="true" enabled="true" authorized="true" uptodate="true" ip="..........." href="/app/rest/agents/id:1">
 <enabledInfo status="true">
  <comment>
   <user username="userName" id="1" href="/app/rest/users/id:1"/>
   <timestamp>20160406T175040+0300</timestamp>
   <text>newcomment</text>
  </comment>
 </enabledInfo>
 <authorizedInfo status="true">
  <comment>
   <user username="userName" id="1" href="/app/rest/users/id:1"/>
   <timestamp>20160406T183033+0300</timestamp>
  </comment>
 </authorizedInfo>
....
</agent>

For build configuration with internal id "btXXX":
Status of the last build: <img src="http://teamcity:8111/app/rest/builds/buildType:(id:btXXX)/statusIcon"/>
Status of the last build tagged with tag "myTag": <img src="http://teamcity:8111/app/rest/builds/buildType:(id:btXXX),tag:myTag/statusIcon"/>

[![Build status](https://teamcity.jetbrains.com/guestAuth/app/rest/builds/buildType:(id:TeamCityPluginsByJetBrains_TeamcityGoogleTagManagerPlugin_Build)/statusIcon.svg)](https://teamcity.jetbrains.com/viewType.html?buildTypeId=TeamCityPluginsByJetBrains_TeamcityGoogleTagManagerPlugin_Build)

{hidden-data}

Example C# code shared by our users to do REST API calls with NTLM authentication and cookies reuse:

{noformat}
using System;
using System.IO;
using System.Net;

namespace TestingSingleSignOnAuthREST
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(GetRestResponse("http://teamcity.jetbrains.com", "/app/rest/server"));
            Console.ReadLine();
        }

        public static string GetRestResponse(string server, string requestStr)
        {
            var cookies = new CookieContainer();
            var request = (HttpWebRequest)WebRequest.Create(server + requestStr);
            request.Timeout = (int)TimeSpan.FromDays(1).TotalMilliseconds;
            request.ContentType = "application/xml";
            request.UseDefaultCredentials = true;
            request.PreAuthenticate = true;
            request.CookieContainer = cookies;

            var resp = request.GetResponse() as HttpWebResponse;
            var reader = new StreamReader(resp.GetResponseStream(), );
            return reader.ReadToEnd();
        }
    }
}
{noformat}
{hidden-data}

  Base64url