API

Feature request: Organization-level API token. Use case and workaround:We use Terraform provider to interact with the CircleCI API, and since CircleCI supports personal and project-level API tokens (but not organization-level API tokens), the current workaround involves service user which generates an API token, which is suboptimal. CCI-I-1546

Currently, using the CircleCI APIs requires manually generating a token. For GitHub apps and other GitHub APIs that already have a GitHub token that is authorized for an organization that is integrated with CircleCI, it would be much nicer if it were possible to make CircleCI API calls using this token (or through some kind of OAuth workflow) rather than having to manually having to generate separate tokens in the CircleCI UI. CCI-I-482

Build artifacts can produce useful information, such as documentation and performance graphs. However, there are typically two different scenarios where someone wants to look at a build artifact: I want to see how this change will modify the existing documentation/performance I want to see the documentation/performance for the latest commit on the master branch For either scenario, seeing the build artifacts for the latest commit on the master branch is important. However, there doesn't currently seem to be a way to expose that concept. Build artifacts are only exposed via URLs that contain the CircleCI build number. I would like CircleCI to expose URLs that contain a branch name, instead of a CircleCI build number. This URL could be used to refer to build artifacts in an arbitrary build. When a client resolves this URL, CircleCI should issue an HTTP redirect to the most recent CircleCI build for the latest commit of that branch. Here's a specific use case: My project builds HTML documentation. I would like to include a link in the README to point the reader to the latest version of this HTML documentation. I would like CircleCI to build and host this documentation for me via the build artifacts feature. I need a stable URL to put in the README file, that will reliably result in the latest version of this HTML documentation. CCI-I-228

Currently this is only available via the GUI. > https://circleci.com/docs/rerun-failed-tests/ This feature request is to introduce this functionality to users via a CircleCI API endpoint

The new "trigger a build by project" endpoint in practice triggers entire workflows and not singular jobs. In other words, it does not support specifying a job to trigger via build_parameters the way the other API job trigger does.It would be greatly appreciated if the new endpoint could be made to support build_parameters so as to target particular jobs and not entire workflows. Our primary use case for wanting to trigger jobs outside of a workflow context via the API is ad-hoc mobile app submissions via our Hubot app in Slack. I imagine there would be other uses - there are plenty of opportunities for CircleCI-powered automation outside of a workflow context. This would be especially helpful given that the other API job triggering endpoint is not supported when using the 2.1 configuration. CCI-I-690

As a CircleCI API user, I want to be able to specify the size of the page - the number of pipelines returned in response to a single request. Also being able to parse with date would be great. This will allow me to control the amount of data being transferred, stored, and processed, thus optimizing interaction with the API and the execution time of my scripts. GET /api/v2/project/project-slug/pipeline?PageSize=50

If I want to turn a trigger off I have to delete it. That's not great. Please fix.

Users are able to trigger pipelines via the API and specify which jobs or workflows to run based on pipeline parameters. However, this flexibility is incompatible with auto cancel redundant builds, as a user can trigger multiple pipelines for a branch, specifying jobs for each pipeline, but only one pipeline can run at a time for that branch.It would be helpful to have a parameter that can allow users to override "Autocancel redundant builds" when triggering pipelines with the API. CCI-I-1680

I would be a great idea, if we as a company could query an api to gain access to our billing information instead of going to the UI and then transfer this our own finance systems.We can see you already have an endpoint called graphql-unstable, but there is no documentation on this, and it is not clear how you expect authentication against this endpoint? CCI-I-1342

Please add git commit SHA parameter to Trigger Pipeline endpoint along with branch and tag . I have a use case for rollback action to a particular commit. Example payload: { "sha": "ebf73d7382bcc3271f7878434e892ac9142dfa99", "parameters": { "deploy_prod": true } }