Permissions

Access in AISquare depends on three things together: a publication's visibility, the user's authentication, and the user's role or membership. Not all data is visible to all users, so your app should check access before fetching protected content.

Publication visibility

Every AI Studio (publication) carries a visibility setting.

In short: public content is open, team content requires workspace membership, and private content requires explicit access.

Permission check

AISquare exposes an endpoint that validates whether a user can access a publication.

POST /aistudios/permission/

{
  "url": "ai-research-studio"
}

It resolves the publication from the url, checks the user's membership and roles, and may set a workspace context for subsequent requests.

How access is resolved

1. Resolve the publication from the url.
2. Check its visibility.
3. Check authentication.
4. Check membership or role.
5. Grant or deny.

Workspace context

When access is granted, AISquare may set a workspace context (a cookie) so later requests are scoped to the right workspace. Send it along on subsequent calls to keep behavior consistent.

Roles and membership

A user can hold different roles within a publication:

• Creator. The owner.
• Co-creator. An editor, reviewer, or other collaborator.
• Workspace member. A member of the workspace.

Roles determine whether a user can view content, edit or manage resources, and see metrics and analytics. See Studios for how creators and co-creators are managed.

Access patterns

Public content needs no check:

user  ->  request  ->  public data returned

Restricted content goes through authentication and a permission check first:

user  ->  authenticate  ->  permission check  ->  access granted

Best practices

• Check before you fetch. Call the permission endpoint before requesting protected data.
• Handle failures. On 401, prompt login; on 404, show not found or restricted. See Errors.
• Cache results. Avoid repeating the same check for the same user and publication.
• Do not assume access. Not every user can see every publication.

Common mistakes

• Skipping the check. Leads to surprise failures on later calls.
• Treating 404 as missing. It can mean access denied.
• Ignoring workspace context. Dropping the cookie causes inconsistent behavior across requests.

Putting it together

1. The user selects a studio.
2. Your backend checks permission.
3. If allowed, fetch the data.
4. If denied, handle the error.

Next steps