API Key - read-only, Note entity only

We want to make an Script Permission role with only read access to the Note entity.
Is there any way to do this other than uncheck EVERY Entity/Field/App option in the permissions matrix?
Conversely, any way to create a Permission Role with NO permissions, and add to it instead?

Hi @schicky

May I ask what is the high-level purpose of this ?

The reason I ask is that Scripts users are usually setup with the API Admin by default, and meant to be used from a secure environment and the running code is in charge of limiting the scope of actions performed. In your case, the code would only ever do a read call, never an update/create/delete.

As you point out, modifying a permissions group en masse is a bit tedious. There are no easy ways that I know to achieve that.

What you describe gives me the impression that you script credentials would be copied in a number of unsecure places and you want to limit its capabilites in case someone decides to get creative.

As a security guideline, a specific script credentials should be used from only one place, so that it is easy to rotate and revoke.


Hi Patrick – thanks for the sanity-check.

This use case is a 3rd party partner that wishes to download Notes locally via the API.

We don’t want any admin-level access and wish to limit access to the Note entity within a specific project.

Rather than a script key, I’m inclined to suggest they use User-based Authentication instead with the API, which would allow for very limited access.

Does this sound right?



Good evening Stephen,

Apologies, I had not realized it was you :slight_smile:

I agree with you, using a regular HumanUser seems the best way to go.

Admittedly, unless you have a suitable Permission Group handy, you will need to clone and tweak an existing one. Which will still be a bit of a pain to review (reading the Summary section of a Permission Group is not what I would call fun or easy) and tailor.

If you give that partner access to the Notes via a service that you write, then you could control exactly which and how entities are accessed. But you may not have the time/resources to create that service.

Hoping that you can get that setup quickly,


1 Like