A service account is a non-human identity — the account an integration or automation acts as when it runs on its own, with no person signed in behind it. Each one holds its own API keys and carries the roles that decide what it can reach, so an outside system gets exactly the access you grant it and nothing more.
The service accounts list
The list of service accounts lives in Setup. Each row is one account, showing its name, the roles assigned to it, how many API keys it holds, and when it was last modified.
Every organisation starts with one built-in account named Automation. It is the identity your automations act as, and the account API keys act through, so an organisation can run integrations without adding anything to this list. To give a particular integration its own roles and keys, select Create Service Account and name the account for the system that will use it.
API keys
An API key is the credential an outside system presents to call Pyron's API as a service account. The key belongs to the account, so a request made with it can do only what the account's roles allow. The KEYS column counts how many keys an account holds.
When you issue a key, Pyron shows its secret value one time. Copy it then and store it somewhere safe: Pyron keeps only a one-way hash of the key, so the value cannot be shown again. When a key is exposed, or the integration behind it is retired, revoke it — any system still presenting a revoked key is turned away.
Copy a key the moment you issue it. Pyron stores only a hash and cannot recover the original value, so a misplaced key has to be revoked and replaced rather than looked up.
For a step-by-step guide to issuing an inbound key and using it in a request, see inbound API keys.
Scoping what they can do
A service account reaches only what its roles grant — the same roles and permissions that govern the people in your organisation. An account that shows No roles in its row can authenticate but touch nothing, which makes its roles the setting that decides an integration's reach.
Give each account the narrowest set of roles its integration needs, and no more. An integration that reads entries but never changes them should hold a role that can view without editing. You manage which roles exist, and what each one allows, on the roles page.
Because your automations act as the built-in Automation account, the roles on that account set how far an automation can reach when it writes back into Pyron. Scope it the same way as any other account: enough to do its job, nothing spare.