A read-only API key does not limit what it can see. For an integration to reach only part of your data, you have to act on the account that generates the key, not only on the key.
Two levels not to be confused: rights and scope
The rights of the key: what it can do
Four boxes to tick at creation: write, read data, read messages, read the calendar. They define the operations that are allowed.
→ Create and manage your API keys (Sesskey)
The scope of the account: what it can see
A key inherits in full the accesses of the account that created it. Generated from your administrator account, it sees all your workspaces, even with writing unticked.
→ Set member rights
A read-only key is still a key that reads everything. This is the most expensive misunderstanding about the API: unticking writing protects the integrity of your data, not its confidentiality. Only a dedicated account limits what can be read.
The procedure, in five steps
1
Create a TimeTonic account dedicated to the integration
With a service email address you control, distinct from that of a person. This account will serve only this integration: it does not leave when a colleague does.
2
Prepare the filtered views
In the tables concerned, create one view per integration, containing only the columns and the rows it needs. Set the unnecessary columns to
Invisible in the Field restrictions window. It is this view that defines the real scope.
3
Invite the account, with the most restricted role possible
Invite it only to the workspaces that are necessary, and give it the least permissive role that still lets the integration work.
4
Generate the key from that account
Sign in with the dedicated account, open its
Settings, section
API keys (SessKey), and create the key ticking only the rights that are needed. A key generated from your own account would undo all the work of the previous steps.
5
Check what the key actually sees
Before putting it into production, make a read call and look at what comes back. It is the only way to confirm that the partitioning works as intended.
The password of your TimeTonic account is required in order to validate the creation of a key. In the case of a dedicated account, it is therefore its own password: keep it in your password manager, the team will need it to renew the key.
Naming conventions
An account and a key have to be identifiable months later, by somebody who was not there when they were created.
| What to name |
Example |
| The dedicated account |
An explicit service address, such as api-reporting@yourdomain.com |
| The API key |
api-make, api-n8n, api-reporting-client: the tool that uses it, not the creation date. |
| The filtered view |
A name that states its destination, such as Metabase export or Client sync Durand. |
What this organisation saves you from
A compromised key stays a contained incident
What leaks is limited to the scope of the filtered view, not to all of your workspaces.
Cutting off an access becomes a safe operation
You know exactly which key serves what, and therefore which one to delete without stopping another integration in production.
→ Revoke an access
Go further
Create and manage your API keys
Step-by-step creation and the detail of the four rights.
Read more →
Go further
Set member rights
The roles available for your dedicated account.
Read more →
Go further
Revoke an access
Cut off a key, a session or a share link.
Read more →