Members and access
Access in Ownlate is a workspace matter. Everyone who can see a project can see it because they are a member of the workspace that owns it — or because the project is open to the world.
Levels
Section titled “Levels”A member joins at a level, and the level is shorthand for a set of permission codes.
| Level | Holds |
|---|---|
owner | Every permission, including deleting the workspace |
admin | Everything except workspace:delete |
translator | workspace:view, members:view, project:view, segment:view, segment:create, translation:write |
viewer | workspace:view, members:view, project:view, segment:view |
The practical difference between translator and admin is translation:approve: a translator writes, an admin signs off.
Permission codes
Section titled “Permission codes”| Code | Allows |
|---|---|
workspace:view | Seeing the workspace and its contents |
workspace:delete | Deleting the workspace |
members:view | Seeing who is in it |
members:manage | Inviting, removing and changing levels |
billing:manage | Plans, payment methods and invoices |
project:view | Opening projects |
project:create | Creating projects, files and releases |
project:archive | Archiving and restoring projects |
project:oss-approve | Approving a project for the open plan |
segment:view | Reading segments and translations |
segment:create | Adding and removing segments |
translation:write | Saving drafts and submitting translations |
translation:approve | Reviewing, approving and rejecting |
Two more exist outside the levels:
translation:suggest— what anybody signed in may do on an open project. It writes nothing until a reviewer accepts the suggestion.platform:projects,platform:plans,platform:users— platform staff only. No amount of seniority in a workspace grants them.
You can see exactly what you hold in a workspace with GET /v1/workspaces/{workspaceId}/users/me/permissions, which is also what the interface uses to decide which buttons to show.
Invites
Section titled “Invites”Workspace → Members → Invite sends a one-time link to an email address, with the level the person will join at. An invite can be resent or revoked while it is pending, and it expires on its own.
Accepting attaches the account that follows the link. Someone who has no Ownlate account yet signs in first and lands back on the invite.
Adding an existing platform user directly, without an email round trip, is also possible — look them up by address and add them at a level.
Audit log
Section titled “Audit log”Every significant action in a workspace is appended to its audit log: members added and removed, projects created and archived, integrations connected. Entries carry the action, its metadata and a timestamp, and nothing can edit or delete them.
Workspace → Audit log, or GET /v1/workspaces/{workspaceId}/audit-log.
API keys
Section titled “API keys”An API key lets your code act as you. Create one under Profile → API keys.
- The key is shown once, at creation. Afterwards you see only its prefix and when it was last used.
- Scopes are permission codes. A key can only ever narrow what you hold — a scope you do not have yourself grants nothing.
- Expiry is optional; after it, the key stops working.
- Revoking takes effect immediately.
Use one key per consumer — a key for CI, a key for your export script — so that revoking one does not stop the others.
SDK tokens
Section titled “SDK tokens”An SDK token is a much smaller thing: it belongs to one project, it can read segments by key and save drafts, and that is all. It is meant to ship inside a browser bundle where anyone can read it. See SDKs and clients.
OAuth applications
Section titled “OAuth applications”An assistant or a third-party application authorises through OAuth, choosing the workspaces it may reach and the permissions it may exercise. Those grants are visible and revocable from your profile. See MCP server.