Skip to content

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.

Note

To view the latest features, enhancements, and fixes for all SaaS connectors, refer to the SaaS Release Notes 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.
  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.

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:
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:
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:
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.