# Integrating SailPoint with Qdrant

Qdrant Cloud is a managed vector database platform used to run, scale, and operate Qdrant clusters. In addition to cluster and backup management, the Cloud control plane provides Identity and Access Management (IAM) for the organization: members (users), roles, and permissions that control who can manage accounts, clusters, API keys, billing, and other Cloud resources. This document provides the instructions required to configure a new direct connection between SailPoint and Qdrant for Quick Compliance use cases. For a reference to the terminology specific to SailPoint products, refer to [Source and Connector Definitions](<https://documentation.sailpoint.com/saas/help/sources/index.html#source-and-connector-definitions>).

> [!NOTE]
>
> To view the latest features, enhancements, and fixes for all SaaS connectors, refer to the [SaaS Release Notes](<https://community.sailpoint.com/release-notes/saas>) page.

## Supported Features

The Qdrant connector supports the following:

### Account Management

- Aggregate Accounts

### Entitlement Management

- Aggregate Roles

### Pagination

The IAM list endpoints used by this source (`ListUsers`, `ListRoles`, `ListUserRoles`) return the full collection in a single JSON envelope (`items` or `roles`). They do not expose skip/limit or cursor fields in the current public API. Leave paging disabled on these HTTP operations unless Qdrant later adds paging parameters to the same paths.

> [!NOTE]
>
> This connector is read-only. It supports test connection, account aggregation, and entitlement aggregation for Quick Compliance. Provisioning, de-provisioning, and write operations are not supported.

> [!IMPORTANT]
>
> Quick Compliance connectors have the following manual aggregation limits within a 24-hour period:
>
> - **Organization Admins**: Limited to 3 manual account or entitlement aggregations per day per source. This limit is cumulative across all admins in the organization.
> - **Regular Users**: Limited to 1 manual account or entitlement aggregation per day per source.
>
> These limits ensure that individual compliance statuses are kept up to date while maintaining continuous compliance monitoring. If you need to run additional aggregations beyond these limits, contact SailPoint Support.

## Prerequisites

Before you configure the Qdrant connector, ensure the following requirements are met:

1. Sign in to [Qdrant Cloud](<https://cloud.qdrant.io/>).
2. Note your Account ID. This is a 36-character UUID. It appears in the Cloud console URL and in every Cloud API path as `{account_id}`.
3. Go to **Access Management \> Cloud Management Keys** and create a Cloud Management Key with at least `read:users` and `read:roles` (see Required Permissions).

   - **Base URL**
   - **Account ID** - the 36-character UUID of the Qdrant Cloud account to govern
   - **API Token** - Cloud Management Key, sent as `Authorization: apikey <key>`
4. Store the token so the `apikey` prefix is present on every request. Either:

   - Save the full header value in the source token field (`apikey <keyId>|<secret>`), or
   - Save only the key and hardcode `apikey` in the HTTP operation header template.

For more detailed information, refer to the [official Qdrant Cloud API documentation](<https://qdrant.tech/documentation/cloud-api/>).

> [!NOTE]
>
> The linked document is not maintained by SailPoint and is subject to change without notice.

## Required Permissions

The Cloud Management Key inherits the permissions of the creating user or assigned role. Aggregation is read-only and requires:

- **read:users** - list account members (`ListUsers` / members).
- **read:roles** - list roles (`ListRoles`) and list a user's assigned roles (`ListUserRoles`).
- **read:account** - recommended so connection tests against account-scoped endpoints succeed.

Built-in system roles on a Qdrant Cloud account typically include:

- **Owner** (`SYSTEM_ROLE_SUB_TYPE_OWNER`) - full account administration, including `delete:account`.
- **Admin** (`SYSTEM_ROLE_SUB_TYPE_ADMIN`) - manage clusters, IAM, keys, and most write operations except deleting the account.
- **Base** (`SYSTEM_ROLE_SUB_TYPE_BASE`) - limited profile or account read (`read:profile`, `read:account`).

Use a key created by an Owner or Admin (or a custom role that includes the read permissions above). A Base-only identity cannot enumerate users or roles.

## HTTP Operations

Configure three operations on the Web Services SaaS source. Replace `{account_id}` with the real 36-character UUID (or `$application.accountId$` only after that attribute exists on the source).

### List Members (Account Aggregation)

- **Operation Type:** Account Aggregation
- **Request:**

```text
curl --location --request GET 'https://api.cloud.qdrant.io/api/iam/v1/accounts/{account_id}/users' \
--header 'Authorization: $application.accesstoken$'
```

- **Root Path:** `$.items`
- **Response mapping:**

| Schema Attribute | Attribute Path |
| --- | --- |
| id | $.id |
| email | $.email |
| status | $.status |
| createdAt | $.createdAt |
| lastModifiedAt | $.lastModifiedAt |

### Get User Roles (Account Aggregation - Child)

- **Operation Type:** Account Aggregation (child of List Members)
- **Request:**

```text
curl --location --request GET 'https://api.cloud.qdrant.io/api/iam/v1/accounts/{account_id}/users/$response.id$/roles' \
--header 'Authorization: $application.accesstoken$'
```

- **Root Path:** `$.roles` - not `$.items`. `ListUserRoles` returns `{ "roles": [ … ] }`. Using `$.items` aggregates accounts with empty entitlements and no error.
- **Response mapping** (account schema only; map attributes that exist on the account):

| Schema Attribute | Attribute Path |
| --- | --- |
| role\_id | $.id |

### List All Roles (Group Aggregation - Role)

- **Operation Type:** Group Aggregation-Role (Entitlement Aggregation for object type Role)
- **Request:**

```text
curl --location --request GET 'https://api.cloud.qdrant.io/api/iam/v1/accounts/{account_id}/roles' \
--header 'Authorization: $application.accesstoken$'
```

- **Root Path:** `$.items` - `ListRoles` returns `{ "items": [ … ] }`.
- **Response mapping** (must match the Role entitlement schema attribute names):

| Schema Attribute | Attribute Path |
| --- | --- |
| role\_id | $.id |
| name | $.name |
| roleType | $.roleType |

The Role schema's Entitlement ID must be `role_id`.