Project-based Tags

The Aurora API allows you to tag projects. You can use the tags to scope a restricted key's access to certain resources.

To create a project with tags, simply include the tags field in the request body of a Create Project or Update Project call while using a standard key, with any tags you'd like to add:

"project": {
  ...,
  "tags": ["my_tag", "my_other_tag"]
}

Scoping Tagged Resources

Your tenant admin can limit the resources that a restricted key has access to. For example, you can allow a restricted key to only List or Retrieve projects with the tag "my_tag".

When creating a restricted key, enable any endpoints which you would like the key to have access to. Endpoints that act on projects, or on resources that belong to a project (such as designs, assets, proposals, and site surveys), support tagged access. For these endpoints you can optionally include any tags as a comma separated list. Not including tags will allow access to all resources for that endpoint. Endpoints that act on tenant-level resources, such as webhooks, users, and teams, do not support tags.

The set of endpoints that support tags grows over time. To see which endpoints accept tags, create or edit a restricted key on the API Tokens page in Settings (sandbox: https://v2-sandbox.aurorasolar.com/settings/api/tokens). When you enable an endpoint that supports tags, a tags field appears for it.

To apply the same tags to many endpoints at once, enter them in the Tags for all tagged endpoints field and select Apply to all. This sets the tags for every endpoint that supports tags, whether or not it is currently enabled, replacing any tags already entered for those endpoints. You can still edit the tags for individual endpoints afterward.

Tag Inheritance

Tags defined on a project are inherited by the resources that belong to the project, such as design, asset, proposal, and site survey resources. To take advantage of an inherited tag, you will need to include the project's tag on each of the endpoints that you wish to scope down.

A Concrete Example

Take a Restricted Key named Key A with the following properties:

  • List Projects: "tag_a"
  • Retrieve Projects: "tag_a"
  • Retrieve Roof Summary: "tag_a"
  • List Assets: "tag_a"
  • Retrieve Asset: "tag_a"

And a Restricted Key named Key B with the following properties

  • List Projects: "tag_b"
  • Retrieve Projects: "tag_b"

Then, when creating projects via API with your Standard Key , the following scenarios exist:

  • Create with "tags": ["tag_a"] -> only Key A will be able to see this project, and view the roof summary or assets of it.
  • Create with "tags": ["tag_b"]-> only Key B will be able to see this project. However it won't be able to retrieve assets because those endpoints were not added to the key.
  • Create with "tags": ["tag_a", "tag_b"] -> Both Key A and Key B will be able to see this project, but only Key A will be able to view the roof summary or assets of it.

This allows for fine grained access of your Aurora resources, both by API endpoint and by project.