***

title: Permissions and access control
description: >-
How access to AISquare resources is controlled and how to handle permissions
correctly.
----------

This guide explains how access to AISquare resources is controlled and how to handle permissions correctly in your application.

***

## Overview

Access in AISquare depends on:

* Publication visibility
* User authentication
* User role and membership

Not all data is accessible to all users, and behavior may change depending on access level.

***

## Publication visibility

Each AI Studio (publication) has a visibility setting.

### Visibility types

| Type      | Description                         |
| --------- | ----------------------------------- |
| `PUBLIC`  | Accessible to all users             |
| `TEAM`    | Restricted to workspace members     |
| `PRIVATE` | Restricted to authorized users only |

### How visibility affects access

**Public**

* Accessible without authentication
* Returns publicly available content

**Team**

* Requires authentication
* User must belong to the workspace

**Private**

* Requires authentication
* User must have explicit access

***

## Permission check flow

AISquare provides a permission validation mechanism.

### Endpoint

```
POST /api/v1/aistudios/permission/
```

### Example request

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

### What it does

* Validates if the user can access the publication
* Checks membership and roles
* May update workspace context

***

## Access logic

The permission flow typically works like this:

1. Resolve publication from URL
2. Check visibility
3. Check authentication
4. Check membership or role
5. Grant or deny access

### Response behavior

| Status | Meaning                                |
| ------ | -------------------------------------- |
| `200`  | Access granted                         |
| `401`  | Authentication required                |
| `404`  | Publication not found or access denied |

### Workspace context

When access is granted:

* AISquare may set a workspace context (cookie)
* This ensures subsequent requests are scoped correctly

***

## Roles and membership

Users may have different roles within a publication:

* **Creator** (owner)
* **Co-creator** (editor, reviewer, etc.)
* **Workspace member**

### Role impact

Roles determine:

* Ability to view content
* Ability to edit or manage resources
* Access to metrics and analytics

***

## Access patterns

### Public content access

```
user → request → public data returned
```

### Restricted content access

```
user → authenticate → permission check → access granted
```

***

## Best practices

### Always validate access

Before fetching protected data, call the permission endpoint.

### Handle failures gracefully

* `401` → prompt login
* `404` → show not found or restricted

### Cache permission results

Avoid repeated permission checks for the same user and publication.

### Avoid assumptions

Do not assume all users have access to all publications.

***

## Common mistakes

### Skipping permission checks

Leads to unexpected failures in API calls.

### Treating 404 as missing data

In some cases, `404` means access denied, not non-existence.

### Ignoring workspace context

This may result in inconsistent behavior across requests.

***

## Putting it all together

1. User selects studio
2. Backend checks permission
3. If allowed → fetch data
4. If denied → handle error

***

## Related pages

* [Authentication](/docs/getting-started/authentication) — set up credentials for permission checks
* [AI Studios](/docs/product/ai-studios) — publication-scoped endpoints
* [Collections](/docs/product/collections) — visibility controls for collections
* [Working with creators](/docs/insights/working-with-creators) — creator and co-creator roles
* [Errors](/docs/reference/errors) — understand 401, 403, and 404 responses
* [Core Concepts](/docs/getting-started/core-concepts) — entity visibility model