Project Restrictions API v2 endpoints now in open preview

We are keeping the momentum going on improving our public API v2 endpoints, and have recently released new Project Restrictions for Contexts API v2 endpoints.

These endpoints allow you to programmatically manage (list, create, and delete) Project Restrictions within a Context.

This will be especially useful for those wanting to incorporate the setting up and configuration of CircleCI projects into your automated processes, and for security-related automation.

You can read more about how to use Contexts and Project Restrictions here and here.

Note: These endpoints are currently labeled as “experimental” which means they can change at any time. It is not advised to use them in production because of this reason.

The API specifications can be found here for get, here for create, and here for delete

We’d love to hear from you! If you have questions or feedback please let us know below.

Hi Olaf,

Is there any way to list projects associated with a specific organization?

We’re looking to easily configure all projects within our organization using the Update project settings endpoint provided in the experimental API


Hi @jctm ! Not specifically, but you could use either


to get projects that are connected to your authenticated user.

Let me know if this is something that can work for you, or if you need something else.

tnx! Olaf

That does help a bit, though one gap here is addressing the projects not yet followed. Are there any ways to perhaps automatically follow all new projects in our organization? That way we could use a “machine” user as the caller of those APIs and would therefore have visibility and access to all project configs at all times?

Alternatively, is there any way to list projects that are not followed by the current user?

Thank you

Hi @jctm tnx for your response! To get more clarity about your usecase, can you tell me with what frequency you would need to “scan” all of your projects, and what kind of amount of projects we’re talking about generally? That would give us more insights in the load it would require.

Also, are these Github OAuth or Bitbucket projects, or another type of projects?

Tnx for your feedback!

Ideally, we wouldn’t need to scan all of our projects, but instead enforce specific project configurations across the board. However, currently any user inside of our organization has permissions to create projects with configurations different than our recommended/required settings. A weekly scan would make sense to us as a week seems to have a good enough impact on how our billing will come out. These are all Github projects. Thank you

Hi @jctm, understood, tnx for your info! Are we talking about 10s or 100s of projects? tnx, Olaf

We’re currently working with 100s of projects

tnx, this is really helpful! Let me discuss this internally, and see what we can do to improve this!