This feature suggestion is for a public API for working with Canvas Themes. Most useful (probably) would be the ability to programatically select an existing Theme. Next steps could be to make public some endpoints for managing Theme details (colours etc.) or making new themes, but this would be a lesser priority, especially given the high quality UI that exists for this already.
Use Case 1 - Theme selector API
Canvas content is refreshed every three weeks from the production environment into the test instance, and more frequently into the beta instance. If an institution uses all three instances, especially with a non-technical audience, there is not much visual feedback as to which instance you are currently accessing. This could lead to user mistakenly performing damaging actions in the production environment by accident.
To mitigate this, my institution uses a garish Theme for the test and beta environments, making is very obvious to the user which environment they are currently in.
However, the lack of an API for switching themes means that every three weeks someone has to manually re-change the non-production environment Themes.
Recommendation: API endpoint which accepts Sub-Account and Theme ID as input parameters, enabling scripted selection of existing Themes.
Use case 2 - Full Theme API public endpoints
In this (admittedly less common, more extreme) example, it may be useful for institutions to be able to modify Themes programatically, e.g. setting new colour values, referencing new images (logos) or, perhaps most usefully, uploading new CSS overlay files.
Regular modification of presentational aspects of a Theme seems unlikely/too much effort to build the API to justify. However, programatic upload of CSS files would be beneficial in many use cases, including those institutions who use CSS overlays within a code management and deployment process.
This API could be to modify existing Themes or make new ones entirely from scratch.
Looking for support for Use Case 1 in the first instance, with discussion around Use Case 2.