TrueMonthReporting needs to read your data. It never needs to change it. Read-only access means the credentials we use can view records but cannot create, edit or delete anything. Here is what that looks like in practice.
The four common methods
| Method | How it works |
|---|---|
| API key with read scopes | Your admin creates a key in the system's settings and ticks only the read permissions. Common in CRMs, phone systems and e-commerce platforms. |
| Sign in and authorize | An admin signs in to the system and approves read-only access for our app. Common in accounting and point-of-sale systems. No key changes hands. |
| Integration user | Your admin creates a dedicated user with a read-only profile. Common in enterprise CRMs and ERPs. Actions are logged under that user, separate from staff. |
| Scheduled export | The system emails or drops a report file on a schedule. Nothing connects to your system at all. |
Why not just share a login?
- A staff login can usually edit and delete, which reporting never needs.
- It breaks when that person changes their password or leaves.
- It mixes reporting activity with a real person's activity in your audit logs.
- It often bypasses multi-factor sign-in, which weakens your security.
How to switch it off
Every method above can be revoked by your admin, from your side, in a minute: delete the key, remove the app authorization, deactivate the integration user, or stop the export. You never need to ask us first.
What we ask for
We send a one-page checklist per system with the exact permissions we need and nothing more. We confirm each connection in writing, and keep a connection log you can see. Read more on our security page.