Permissions and roles
How the key owner's role, brand access and the company's plan decide what a key may do.
A key never has its own permissions: it uses the permissions of the person who created it, at the moment of the request. If that person's role changes, every one of their keys changes with it.
By role#
| What | Owner | Admin | Manager | Staff |
|---|---|---|---|---|
| Read records of brands they can access | yes | yes | yes | yes |
| Create and change records | yes | yes | yes | yes |
| Delete records | yes | yes | yes | no |
| Read invoices | yes | yes | yes | yes |
| See and revoke everyone's keys | yes | yes | no | no |
| Switch API access on or off | yes | yes | no | no |
Staff can be limited to some brands. Their keys see only those brands; any other brand_id is answered with 422 validation_failed ("is not a brand you can access in this company").
By key access#
A Read only key gets 403 insufficient_scope for POST, PATCH and DELETE, whatever the person's role.
By company state#
| Company state | Reads | Writes |
|---|---|---|
| Trial or active subscription | yes | yes |
| Payment failed (past due) | yes | yes (grace period) |
| Trial ended, or subscription cancelled | yes | no — 403 permission_denied |
| Suspended | no | no |
| API access switched off | no | no |
One company per key#
A key works only inside the company it was created in. IDs from another company are answered with 404 not_found, the same answer as for IDs that do not exist, so nobody can find out whether a record exists elsewhere.
TeknoCare#
TeknoCare staff cannot create keys for your company and cannot use your keys. Keys are stored only as fingerprints.