Unable to access v2 APIs with project-specific API tokens

[ueokande]

CircleCI v1 API supports both project-specific API tokens and user's API tokens to get and start jobs on our private repositories. Although we can use personal API tokens to manage our private repository on v2 API, project-specific API tokens do not work.

For v1 APIs, we can get job information on our private projects by the following curl:

$ curl -sSfL -u"${CIECLE_TOKEN}:" "https://circleci.com/api/v1.1/project/$PROJECT_SLUG/${BUILD_NUM}"
{
  "compare": null,
   ...
}

where CIRCLE_TOKEN is allowed with both project-specific API tokens and personal API tokens.

For v2 APIs, we can use personal API tokens to access our private repository:

$ curl -u"${PERSONAL_TOKEN}:" https://circleci.com/api/v2/project/$PROJECT_SLUG/job/$BUILD_NUM
{
  "web_url" : "https://circleci.com/gh/our-org/repo-name/123456",
  ...
}

but using project-specific tokens returns 404:

$ curl -u"${PROJECT_SPECIFIC_TOKEN}:" https://circleci.com/api/v2/project/$PROJECT_SLUG/job/$BUILD_NUM
{
  "message" : "Job not found"
}

The v2 API should also supports project-specific API tokens.

[AniaMakes]

Seeing as nobody from CircleCI answered you here, I'm going to post the reply I got from them today about this when I raised a support ticket.

Thanks for writing in. I guess the reason behind for personal API is being used for API is triggering build should be someone, not the project itself. On UI, you can see who actually triggered the build - it means the build is triggered by the user, so it's natural that personal keys are used to trigger the API. Also, for the successful builds permissions for read/write is necessary but it's only available for the member in the organization.

What I'd like to recommend is to create one more additional Github/CircleCI account for API, and use the account's personal token so that you can deal with any other situation no matter team members left or not.

[darrikonn]

^ If that's the expected workaround, then it'd be a nice to be able to send the user that triggered the original workflow job in the payload of the pipeline triggering.
This is mainly so that the UI can display who "owns" the current trigger, instead of having this joint "Github/CircleCI account for API" that owns all the jobs. Makes it harder to track your own build in the UI.

[sulami]

The two reasons why project-tokens are so problematic are billing and the paper trail.

Because billing is by seat, project tokens obviously open up a plethora of opportunities for abuse.

The paper trail is important for many of our larger or governmental customers, who need the ability to know who performed a certain action, and this needs to be reasonably tamper-proof.

That being said we're looking at what we can do to bring project-tokens to the v2 API. I don't know yet what that will look like, and we don't have a specific timeline, but we are thinking about it.