---
title: User Profile Entity
url: https://docs.kaltura.com/docs/events-collaboration/user-profile-api/user-profile-user-profile-entity
---

## User Profile Entity

| Field | Type | Description |
|-------|------|-------------|
| `id` | string | Auto-generated profile ID (read-only) |
| `partnerId` | integer | Partner ID from KS (read-only) |
| `appGuid` | string | App Registry GUID this profile belongs to (immutable after creation) |
| `userId` | string | Kaltura user ID (immutable after creation) |
| `status` | string | `enabled`, `disabled`, or `deleted` |
| `profileData` | object | Custom JSON — registration form data, user attributes, etc. |
| `loginData` | object | Login tracking (see section 4.1) |
| `eventData` | object | Event attendance lifecycle (see section 4.2) |
| `appData` | object | Application-specific JSON metadata |
| `createdAt` | string | ISO 8601 timestamp, e.g. `"2026-04-09T04:56:27.940Z"` (read-only) |
| `updatedAt` | string | ISO 8601 timestamp, e.g. `"2026-04-09T04:56:27.940Z"` (read-only) |
| `deletedAt` | string | ISO 8601 timestamp, set on soft-delete (read-only) |
| `objectType` | string | Always `"UserProfile"` in responses (read-only) |

A profile is uniquely identified by the combination of `partnerId` + `appGuid` + `userId`. Each user can have one active (non-deleted) profile per app. After a profile is soft-deleted, a new one can be created for the same user + app combination.

#### User ID Case Sensitivity

User IDs containing `@` (email addresses) are matched **case-insensitively** — creating a profile for `User@Example.com` when one already exists for `user@example.com` returns `USER_ALREADY_ASSOCIATED_TO_APP_GUID`. User IDs without `@` are matched **case-sensitively**.

### 4.1 Login Data

Tracks the user's most recent login activity. Not auto-updated — must be set explicitly via `add` or `update`.

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `lastLoginDate` | string | Yes (within loginData) | ISO 8601 timestamp of last login |
| `lastLoginType` | string | Yes (within loginData) | Login method: `sso`, `emailPass`, `magicLink`, `simpleLogin`, or `guestLogin` |

### 4.2 Event Data

Tracks the user's event attendance lifecycle. This is the primary use case for Events Platform integrations.

| Field | Type | Writable | Description |
|-------|------|----------|-------------|
| `regOrigin` | string | Yes | How the user registered (see values below) |
| `attendanceStatus` | string | Yes | Current attendance status (see lifecycle in section 4) |
| `userRegistrationType` | string | Yes | Attendance type requested: `virtualAttendanceRequest`, `inPersonAttendanceRequest`, or `both` |
| `attendanceType` | string | Yes | Confirmed attendance type: `virtualAttendanceConfirmed`, `inPersonAttendanceConfirmed`, `both`, or `none` |
| `allowedAttendanceType` | string | Yes | Allowed attendance: `virtualAttendanceAllowed`, `inPersonAttendanceAllowed`, `both`, or `none` |
| `isRegistered` | boolean | Yes | Registration flag (default: `false`) |
| `previousAttendanceStatus` | string | Read-only | Auto-set to previous status on each `attendanceStatus` change |
| `statusUpdateTime` | string | Read-only | ISO 8601 timestamp, auto-set when `attendanceStatus` changes |
| `firstAttendedStatusTime` | string | Read-only | ISO 8601 timestamp, auto-set on first transition to `attended` or higher. **Set only once — never overwritten.** |

#### Registration Origin Values

| Value | Description |
|-------|-------------|
| `registration` | Self-registered via form |
| `invite` | Invited by organizer |
| `webhook` | Registered via webhook/integration |
| `sso` | Registered via SSO |
| `admin` | Registered by administrator |