A key that can change a customer record is not a read-only key. We do not store it. We do not pull against it.
That is the whole rule. What changes is how you prove it, because not every PSA will let you ask the question safely.
An MSP does not hand you their book because they liked a slide. They hand you a credential. That credential has whatever rights the last person who set up the API member left on. Sometimes that is inquire-only. Sometimes it is inquire plus add plus edit, because an integration asked for it a year ago and nobody took it back.
If we connect through a key that can write, we have accepted the ability to mutate their companies, their tickets, their invoices. Calling that read-only because a setup form said so is a comment. We will not run a client book on a comment.
The obvious move is to trust the vendor's scope string.
The obvious move is to trust the vendor's scope string. If nothing says write, call it safe. That is how a role named something like "Customers Read Write" gets certified, because the word read appears in it.
What changes is how you prove it, because not every PSA will let you ask the question safely.
ConnectWise
a write that must fail
Halo
we refuse to try
Pilot is not a softer live.
Do not read that as Halo being further along. It is not. ConnectWise and NinjaOne are live: whole book, read-only, proven against a real tenant. HaloPSA is pilot: one client to start. HubSpot is next: designed, not connectable today. Pilot is not a softer live.
The free look, Client 360, is that same promise. Read-only. Nothing writes back. What we do after you have seen the book is a separate conversation, not a connect-time surprise.
If you are the person who will mint the member, make it boring. Inquire. No add. No edit. The boring outcome is the point.
A credential that can write does not get in. We will keep saying it. The proof will keep changing shape when the vendor does. The rule will not.