The smenso Integration API follows the same permission and privacy logic as the smenso application.

smenso distinguishes between:

• privacy (who can see a project/task)
• access (who can modify a project/task)

These rules apply consistently across all APIs.

All operations - whether creating, updating, or deleting data - respect the user’s workspace role, object-level permissions, and any restrictions applied to individual projects, tasks, or reports.

Every API request is executed on behalf of the user whose personal API token is used. This means the API enforces the same access rights, visibility rules, and editing restrictions that apply in the UI.

Permission Principles

1. User roles determine the baseline permissions

Administrators, members, restricted members, read-only users, and guests each have access rights that define what they are allowed to view or edit. These permissions automatically apply to all API requests.

2. Object-level restrictions are fully respected

If editing is restricted at the project or task level - for example via custom role settings or restricted editing permissions - API calls cannot override these rules. Attempts to modify protected content will result in corresponding ticket messages.

3. Only visible data can be retrieved

The API returns only the data the authenticated user is allowed to see in the UI. Hidden projects, tasks, or fields remain inaccessible.

4. Editing restrictions affect POST/DELETE operations

If a user does not have permission to edit or delete a specific object:

• The request is blocked
• No data is changed
• The ticket response includes appropriate warning or error messages

5. Publishing restrictions apply to certain entities

For objects with state-based restrictions (e.g., published status reports), the API behaves exactly like the UI: Once an item is locked due to its state, no updates are permitted.