AppVeyor

Cancel a queued or running build, via DELETE /api/builds/{accountName}/{projectSlug}/{buildVersion}. It STOPS WORK IN FLIGHT and cannot be resumed -- restarting means queuing a new build with 'Start build' -- and a cancellation partway through a deployment step leaves whatever that step had already done. `buildVersion` is the version STRING (`1.0.7`); the build record survives, so this is not 'Delete build'. Answers 204 with no body.

PERMANENTLY DELETE one build record and its logs and artifacts, via DELETE /api/builds/{buildId}. Addressed by the NUMERIC `buildId` -- the version string is what 'Cancel build' takes -- and there is no undelete. The project and its other builds are untouched. Answers 204 with no body, so confirm by reading the history rather than by reading this reply.

REVOKE AN OUTSIDE USER'S ACCESS to this account, via DELETE /api/collaborators/{userId}. Their own AppVeyor account is untouched -- what is destroyed is their role on this one -- and restoring it means inviting them again with 'Add collaborator'. Answers 204 with no body.

PERMANENTLY DELETE a deployment environment, via DELETE /api/environments/{deploymentEnvironmentId}. Its provider settings, its stored target credentials and its access key go with it, and there is no undelete -- recreating it means re-entering every secret. Projects whose appveyor.yml deploys to this environment by name start failing. What was already deployed is not touched. Answers 204 with no body.

PERMANENTLY DELETE a project and everything AppVeyor holds for it -- its settings, its environment variables, its whole build history, the build logs and the artifacts -- via DELETE /api/projects/{accountName}/{projectSlug}. AppVeyor publishes no undelete and no API that recreates the history; 'Add project' would make a NEW project on the same repository with an empty past. Answers 204 with no body, so the 204 is not evidence anything was there.

Clear a project's build cache via DELETE /api/projects/{accountName}/{projectSlug}/buildcache. The project, its settings and its build history are untouched -- what is destroyed is the cached dependency/output directories, so the next build rebuilds them and takes longer. This is the standard remedy for a build that is failing on stale cached state. Answers 204 with no body.

PERMANENTLY DELETE a role, via DELETE /api/roles/{roleId}. The permission matrix goes with it and there is no undelete -- recreating it means 'Add role' plus a full 'Update role'. Deleting a role people currently hold changes what those people can do, so read 'Get users' and 'Get collaborators' first. Answers 204 with no body.

REVOKE A PERSON'S ACCESS to the AppVeyor account by deleting their user, via DELETE /api/users/{userId}. It destroys the account user rather than any build data, and getting it back means re-creating them with 'Add user' and a new password. Deleting the last administrator can leave the account unadministrable. Answers 204 with no body.

The full console log of ONE build job, via GET /api/buildjobs/{jobId}/log. `jobId` comes from a build's `jobs[]` -- read it with 'Get project last build' or 'Get project build by version'; a build with several matrix jobs has one log each. AppVeyor answers a text stream rather than JSON, so this tool returns `{"raw": "<the log>"}`. Measured 2026-09-25: a job id that does not exist answers 404, and a whole build log can be large.

Every collaborator on the connected account, via GET /api/collaborators: a person from ANOTHER AppVeyor account who has been given a role on this one. Each row carries `userId`, `roleId`, `roleName` and whether they are the owner. This is a different list from 'Get users', which is the account's own users.

One collaborator with the ACCOUNT'S FULL ROLE LIST beside them, via GET /api/collaborators/{userId}. The reply is `{user, roles}`, and the roles array is where the `roleId` for 'Update collaborator' comes from.

One deployment in full, via GET /api/deployments/{deploymentId}: the build that was deployed, the environment it went to, each deployment job with its status and timings, and the overall outcome. This is how to follow a deployment 'Start deployment' queued -- poll it until `status` leaves `queued`/`running`.

Every deployment environment on the account, via GET /api/environments: its `deploymentEnvironmentId`, name and provider (AzureBlob, AzureCS, FTP, Agent, and the rest of AppVeyor's deployment providers). The settings and secrets are not here -- 'Get environment settings' is the one that returns them.

The deployment history of ONE environment, via GET /api/environments/{deploymentEnvironmentId}/deployments: which builds of which projects went there, when, and how each ended. The per-PROJECT view of the same records is 'Get project deployments'.

One deployment environment's full configuration, via GET /api/environments/{deploymentEnvironmentId}/settings. READ THE REPLY AS CREDENTIAL MATERIAL: `settings.providerSettings` is where the deployment target's own secrets live -- AppVeyor's documented FTP sample carries a `password` entry -- and each value is `{isEncrypted, value}` with the value present. This is also the document 'Update environment' expects back whole.

Every project on the connected AppVeyor account, each with its repository (type, name, branch), its slug -- the `projectSlug` every other project tool takes -- its NuGet feed and its most recent build, via GET /api/projects. This is the tool to call first: nothing else here can be addressed without the `accountName`/`projectSlug` pair it returns. It is not paged and takes no arguments.

One project together with its LAST build and that build's jobs, via GET /api/projects/{accountName}/{projectSlug}. The reply is `{project, build}`, and `build.jobs[].jobId` is the id 'Download build log' needs. Measured 2026-09-25: an account or slug that does not exist answers 404 rather than 401, so a 404 here means the pair is wrong, not that the key is.

The last build of ONE branch of a project, via GET /api/projects/{accountName}/{projectSlug}/branch/{buildBranch}. The reply is the same `{project, build}` shape as 'Get project last build'; this is the narrowing of it that answers 'is master green'.

One named build of a project, via GET /api/projects/{accountName}/{projectSlug}/build/{buildVersion}. `buildVersion` is AppVeyor's own version STRING (`1.0.7`), not the numeric `buildId` -- 'Delete build' is the one that takes the id. The reply is the same `{project, build}` shape as 'Get project last build'.

A project's deployment history -- which builds went to which environments and how each ended -- via GET /api/projects/{accountName}/{projectSlug}/deployments. AppVeyor caps and defaults `recordsNumber` at 20, so asking for more returns 20.

A page of a project's build history, newest first, via GET /api/projects/{accountName}/{projectSlug}/history. `recordsNumber` is required, and paging is by `startBuildId` -- pass the last `buildId` of the page you have to get the ones before it. This is the only tool that reads more than one build at a time.

A project's FULL settings document via GET /api/projects/{accountName}/{projectSlug}/settings: the build configuration, matrix, scripts, artifacts, deployment targets, notifications and the project's security descriptor. This is the document 'Update project' expects back -- read it, change what you mean to change, and send the whole thing, because that call REPLACES the project rather than patching it.

A project's environment variables via GET /api/projects/{accountName}/{projectSlug}/settings/environment-variables. READ THE REPLY AS CREDENTIAL MATERIAL: each entry is `{name, value:{isEncrypted, value}}`, and AppVeyor's own documented sample shows an `isEncrypted: true` variable returning its secret IN CLEAR TEXT (`"value":"very-secret-key-in-clear-text"`). `isEncrypted` describes how the value is stored and shown in the web UI, not whether this API withholds it.

The project's appveyor.yml as TEXT, via GET /api/projects/{accountName}/{projectSlug}/settings/yaml. AppVeyor answers `text/plain`, not JSON, so this tool returns `{"raw": "<the yaml>"}` -- the YAML is the string under `raw` and is not parsed here. Note this reads the settings STORED ON THE PROJECT; a repository that carries its own appveyor.yml is built from the repository copy instead unless the project is configured to ignore it.

Every role the account defines, via GET /api/roles: `roleId`, `name`, and `isSystem` for the two AppVeyor ships (Administrator, User). This is the tool that supplies the `roleId` every user and collaborator call takes. It is also the endpoint AppVeyor's own PowerShell, C# and curl samples use as the canonical authenticated call, and the one Agentic Fabriq probes a pasted key against.

One role with its FULL PERMISSION MATRIX, via GET /api/roles/{roleId}: the `groups` array names every permission AppVeyor defines and whether this role is allowed it -- Projects (ManageProjects, UpdateProjectSettings, RunProjectBuild, DeleteProjectBuilds), Environments, Account, Users, Roles and User (ConfigureApiKeys, 'Generate API keys'). That last one is what decides whether a person can mint the API token this integration connects with. It is also the document 'Update role' expects back whole.

Every user on the connected AppVeyor account, via GET /api/users: name, email, the role each holds and their build-notification settings. These are ACCOUNT USERS -- people who sign in to this account -- which is a different list from 'Get collaborators'. The `userId` values here are what 'Get user', 'Update user' and 'Delete user' take.

One account user with the ACCOUNT'S FULL ROLE LIST beside them, via GET /api/users/{userId}. The reply is `{user, roles}` -- the roles array is every role the account defines, which is how a caller finds the `roleId` to send to 'Update user'.

QUEUE A BUILD, via POST /api/builds. ONE endpoint, three documented shapes, and the body chooses between them: `branch` alone builds that branch's most recent commit, `branch` + `commitId` builds that specific commit, and `pullRequestId` (instead of both) builds a pull request. `environmentVariables` applies to this run only. THIS SPENDS BUILD MINUTES and runs whatever the project's appveyor.yml says -- including its deployment steps, which can reach production -- so it is a real side effect, not a read. The reply is the queued build with its `buildId` and `version`, status `queued`.

GIVE SOMEONE OUTSIDE THIS ACCOUNT ACCESS TO IT, via POST /api/collaborators. They are identified by email and granted `roleId`, so read 'Get roles' first rather than copying a number -- an administrator role hands over the account. Answers 204 with no body; read 'Get collaborators' back to see the result.

DEPLOY A BUILD TO AN ENVIRONMENT, via POST /api/deployments. THIS REACHES THE TARGET SYSTEM -- an FTP site, an Azure service, a deployment agent on a real server -- so it changes something outside AppVeyor and there is no dry run. The build is named by `buildVersion` (the version string) and the environment by `environmentName`. The reply is the queued deployment with its `deploymentId`; follow it with 'Get deployment'.

Create a deployment environment, via POST /api/environments. THE BODY CARRIES THE DEPLOYMENT TARGET'S OWN CREDENTIALS in `settings.providerSettings` -- AppVeyor's documented sample sends an FTP password -- so mark secret entries `isEncrypted: true`. The reply includes the generated `environmentAccessKey`, which is itself credential material. Creating an environment does not deploy anything; 'Start deployment' does.

Add a repository to the account as a new AppVeyor project, via POST /api/projects. The reply carries the `slug` AppVeyor minted, which is NOT always the repository name -- a collision gets a suffix (`demo-app-335`) -- so read it back rather than assuming it. The account must be able to see the repository already: AppVeyor's authorization of the source-control provider is set up in its web UI and there is no API for it.

Create a role on the account, via POST /api/roles. It takes a NAME ONLY: the role is created with every permission denied, and the permission matrix is set afterwards with 'Update role'. The reply is the new role's document, which is the one to edit and send back.

Create a user on the connected AppVeyor account, via POST /api/users. THIS GRANTS SOMEBODY ACCESS: `roleId` decides what they can do, so read 'Get roles' first rather than copying a number. Prefer `generatePassword: true` -- the `password`/`confirmPassword` pair travels in the request body in clear text. Answers 204 with no body, so read 'Get users' back to find the id that was created.

Change which role a collaborator holds on this account, via PUT /api/collaborators. Both ids travel in the BODY. This is a privilege change in both directions -- promoting hands over more of the account, demoting can take away access somebody's automation depends on. Answers 204 with no body.

Stop a deployment that is already running, via PUT /api/deployments/stop. IT INTERRUPTS WORK ON A REAL TARGET and cannot be resumed: whatever the deployment had already written stays written, so the target can be left half-updated and the remedy is a fresh 'Start deployment', not a retry of this one. Answers 204 with no body.

REPLACES a deployment environment's configuration, via PUT /api/environments. A whole-document write: read 'Get environment settings', change what you mean, and send it back -- a partial `settings` object drops the provider settings and environment variables it omits, which for a deployment target means dropping its credentials and breaking every later deployment to it.

REPLACES a project's settings via PUT /api/projects, and it is a whole-document write rather than a patch: AppVeyor's own sample body is the entire settings object. THE SAFE SEQUENCE IS READ-MODIFY-WRITE -- call 'Get project settings', change the fields you mean, and send that document back. A partial body silently drops every setting it omits, including build scripts, the build matrix, artifact rules, deployment targets and the project's security descriptor. Answers 204 with no body.

Set the number the project's NEXT build will take, via PUT /api/projects/{accountName}/{projectSlug}/settings/build-number. The narrow alternative to 'Update project' for this one field, and the reason to prefer it: the full update replaces the whole settings document. Lowering the number can make a later build carry a version string an earlier one already used. Answers 204 with no body.

REPLACES a project's whole environment-variable set, via PUT /api/projects/{accountName}/{projectSlug}/settings/environment-variables. THE BODY IS A JSON ARRAY AND IT IS THE COMPLETE LIST: any variable not in it is deleted, so read the current set with 'Get project environment variables' and send it back with the change applied. Each entry is `{name, value:{isEncrypted, value}}`; set `isEncrypted` true to have AppVeyor store the value encrypted and mask it in build logs. Answers 204 with no body.

REPLACES the project's stored appveyor.yml, via PUT /api/projects/{accountName}/{projectSlug}/settings/yaml. The body is PLAIN TEXT, not JSON: pass the whole YAML document as the `body` string and Agentic Fabriq sends it with `Content-Type: text/plain`. Whole-document, so read the current YAML with 'Get project settings in YAML' first -- whatever is sent becomes the entire build definition. Answers 204 with no body.

REWRITE A ROLE'S PERMISSIONS, via PUT /api/roles. THIS IS THE ACCOUNT'S ACCESS CONTROL and it is a whole-document write: read the role with 'Get role', flip the `allowed` flags in `groups`, and send the document back. A partial `groups` array takes away every permission it omits, and granting ManageProjects, UpdateAccountDetails or the Users/Roles permissions hands over most of the account. The reply is the updated role.

Update an account user, via PUT /api/users. The user is named by `userId` IN THE BODY -- there is no id in the path. It is a whole-record write in AppVeyor's own sample, so read 'Get user' first and send the fields back rather than a bare pair. `roleId` IS A PRIVILEGE CHANGE. Answers 204 with no body.