Authentication
One key, one company.
The interface has no sessions and no login form. Every request carries its key, and the key carries everything known about the caller.
What a key looks like.
The prefix tells you which kind of secret you pasted. KRONENWERK stores only a hash, so a lost key is replaced rather than recovered.
The binding
A key never changes company.
Anyone working in two businesses holds two keys. A key belongs to the company it was issued in; it does not follow its owner, and no header and no path can change that. The call to /ich names the company so you can check rather than assume.
Scopes, and what they really permit.
On the left the name you grant; on the right the permission KRONENWERK checks internally. Both appear because a security review asks about the second, and "trust us" is not an answer. Reading and writing are separate: neither implies the other.
| Scope | Permission |
|---|---|
| customers:read | VIEW_CUSTOMERS |
| customers:write | EDIT_CUSTOMERS |
| invoices:read | VIEW_INVOICES |
| invoices:write | EDIT_INVOICES |
| transactions:read | VIEW_TRANSACTIONS |
| transactions:write | EDIT_TRANSACTIONS |
| reports:read | VIEW_REPORTS |
| companies:read | VIEW_COMPANY_SETTINGS |
| webhooks:write | MANAGE_WEBHOOKS |
No key can do more than its issuer.
At issue the requested scopes are intersected with what the issuing person themselves may do. Somebody who may not see invoices cannot build a key that can — so the interface is not a way around the product's own permissions.