> For the complete documentation index, see [llms.txt](https://docs.digitalsamba.com/reference/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digitalsamba.com/reference/sdk/events/apperror.md).

# appError

Emitted when something unexpected or not allowed happens in the room.

#### Here is a list of the possible error names:

* `permissions-rejected` -> emitted when user tries to screen share, but browser doesn't have enough permissions for it
* `not-allowed` -> emitted when a not allowed action was requested by the user. For example if a user tries to start a recording and recording is not supported in the room, you will receive a `not-allowed` type.
* `forbidden-action` -> emitted when a forbidden action was requested by the user. For example if a user tries to end a session and doesn't have a permission to do so, then the `forbidden-action` type.
* `authorization-failed` -> emitted when a user's authorization into the room is rejected — for example a display name that fails room validation.
* `command-failed` -> emitted when an SDK method call fails to be processed on the room side. The `data.command` field tells you which method failed. **If `data.command` is `"connect"`, treat this as fatal**: the room did not finish loading and will not recover on its own — reload the iframe or show your own error state rather than treating it as a single failed call.

#### Sample payload

```json
{
  "type": "appError",
  "data": {
      "name": "not-allowed",
      "message": "Recording disabled. You’ll need to edit this room’s properties to record sessions in this room",
      "data": {
         "type": "recording"
      }
  }
}
```

Starting from `v0.0.58` of `@digitalsamba/embedded-sdk`, `not-allowed` can also occur when you call a session-only command (recording, screenshare, whiteboard actions, remote-user actions, hand raise/lower, and similar) before you've joined the session, or after you've left or the session has ended. In that case `data.type` is `"not-joined"` and `data` also includes the command name:

```json
{
  "type": "appError",
  "data": {
    "name": "not-allowed",
    "message": "Command \"removeUser\" requires an active session",
    "data": {
      "type": "not-joined",
      "command": "removeUser"
    }
  }
}
```

If your integration inspects `data` on `not-allowed` errors, make sure it tolerates `data.type` values it doesn't recognize yet and the additional `data.command` field — don't assume `data` only ever has a `type` key.

```json
{
  "type": "appError",
  "data": {
      "name": "forbidden-action",
      "message": "Forbidden action. This participant is not allowed to end session",
      "data": {
         "type": "end-session"
      }
  }
}
```

```json
{
  "type": "appError",
  "data": {
    "name": "authorization-failed",
    "message": "User authorization failed",
    "data": {
      "message": "<underlying error message>"
    }
  }
}
```

```json
{
  "type": "appError",
  "data": {
    "name": "command-failed",
    "message": "Failed to process SDK command \"startRecording\"",
    "data": {
      "command": "startRecording"
    }
  }
}
```

`message` on `command-failed` always follows the template `Failed to process SDK command "<command>"`, where `<command>` is the exact method/command name you called.

#### Sample subscription code

```javascript
sambaFrame.on('appError', (error) => {
  console.log(error);

  /* outputs  
    {
      name: 'not-allowed',
      message:
        'Recording disabled. You’ll need to edit this room’s properties to record sessions in this room',
      'data': {
         'type': 'recording'
      }
    }
  */
});
```